Cisco Confidential - Limited Release

Ultra Packet Core CUPS User Plane Administration Guide, Release

21.22
First Published: 2020-12-17
Last Modified: 2021-02-12

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
 Cisco Confidential - Limited Release

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of
the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (1721R)
© 2020-2021 Cisco Systems, Inc. All rights reserved.
 Cisco Confidential - Limited Release

CONTENTS

CHAPTER 1 Overview 1

Product Description 1
Supported Features and Functionality 3
3GPP ULI Enhanced Reporting Support 3
AAA Server Group 3
APN Configuration Support 3
Asynchronous Core Transfer Support for egtpinmgr 4
Charging Data Records to HDD 5

GTP-C Path Failure Enhancements and Improved Debugging Tools 5

Location Based DNS and PCSCF IP Address Selection 6

MPRA Support 6
QUIC IETF Implementation 7
Configuring QUIC IETF 7
Optimization for egtpinmgr Recovery 7
Quota Hold Time Support 7

S-GW Paging Enhancement 8

Session Recovery in User Plane 9
SRVCC PS to CS Handover Indication and the QoS Class Index IMS Media Configuration Support
9

Support for ip hide-service-address CLI Command 11

TFT Suppression for Default Bearer 11
Feature Description 11
Configuring TFT Suppression 12
How It Works 12
Call Flows 13
P-GW Data Session 13

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
iii
 Cisco Confidential - Limited Release
Contents

S-GW Data Session 14

Support for Addition, Deletion and Updation of Dedicated Bearers for S-GW 17

Support for Collapse Call 18

P-GW Session Reporting with Gy Interface 22
P-GW Session Reporting with Gz Interface 31
Bit Rate Mapping Support 33
Standards Compliance 34

CHAPTER 2 Configuring User Plane in CUPS 35

Configuring User Plane Service 35
Associating GTP-U Service with User Plane Service 36
Associating Sx Service to User Plane Service 37
Recommended Timers 37
Recommended Configurations 38
Example Configurations in CP 38

Example Router Configurations 41

Example Configurations in UP 42

Example SRP Configurations 43

CHAPTER 3 Monitoring and Troubleshooting User Plane in CUPS 45

Monitoring and Troubleshooting User Plane in CUPS 45
SNMP Traps 45
Show Commands 46
show configuration 46
show module p2p user-plane-ipv6-addr 46

show saegw-service all 46

show saegw-service name 46
show service all 46
show subscriber all 47
show subscribers user-plane-only all 47

show subscribers user-plane-only called/seid called/seid flow flow-id flow-id 47

show subscribers user-plane-only called/seid called/seid flows full 48

show subscribers user-plane-only called/seid called/seid flows 49

show subscribers user-plane-only callid call_id pdr all 49

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
iv
 Cisco Confidential - Limited Release
Contents

show subscribers user-plane-only callid/seid callid/seid pdr full all 50

show subscribers user-plane-only callid/seid callid/seid pdr id pdr-id 51

show subscribers user-plane-only flows 53

show subscribers user-plane-only full all 53
show subscribers user-plane-only seid seid pdr all 55
show user-plane-service [ all | name name ] 56

show user-plane-service statistics all 56

CHAPTER 4 Smart Licensing 61

Revision History 61
Overview 61
Cisco Smart Software Manager 62
Smart Accounts/Virtual Accounts 62
Smart Licensing Mode 62
Request a Cisco Smart Account 63
Software Tags and Entitlement Tags 63

Configuring Smart Licensing 66

Monitoring and Troubleshooting Smart Licensing 67

CHAPTER 5 1:1 User Plane Redundancy for 4G CUPS 69

Revision History 69
Feature Description 69
How it Works 69
Configuring 1:1 User Plane Redundancy for 4G CUPS 79
Configuring BFD Monitoring Between Active UP and Standby UP 79

Flagging BGP Monitoring Failure 80

Configuring Sx Monitoring on the Active UP and Standby UP 81

Configuring SRP over IPSec on the Active UP and Standby UP 81

Configuring VPP Monitor on Active UP and Standby UP 83

Preventing User Plane Switchback 83

Resetting Sx Monitor Failure 84
Monitoring and Troubleshooting 84
Show Command(s) and/or Outputs 84
show srp monitor bfd 84

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
v
 Cisco Confidential - Limited Release
Contents

show srp monitor bgp 85

show srp monitor sx 85
show srp monitor vpp 85

CHAPTER 6 5G NSA for SAEGW in CUPS 87

Feature Description 87

CHAPTER 7 Access Control Lists 89

Revision History 89
Feature Description 89
Configuring Access Control Lists 89
Monitoring and Troubleshooting 90
Show Command(s) and/or Outputs 90
show sub user-plane-only full all 90

CHAPTER 8 ADC Over Gx 93

Feature Description 93
How It Works 94
Limitations 95
Licensing 95
Configuring ADC over Gx 95
Monitoring and Troubleshooting 96
Monitor Protocol 96
Show Command(s) and/or Outputs 96
On C-Plane 96
On U-Plane 96

CHAPTER 9 Addition of IP Pool in IP Group 99

Revision History 99
Feature Description 99
How it Works 100
Monitoring and Troubleshooting 100
Show Command(s) and/or Outputs 100
show ip user-plane verbose 100

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
vi
 Cisco Confidential - Limited Release
Contents

CHAPTER 10 APN ACL Support 101

Revision History 101

Feature Description 101
Troubleshooting 102

CHAPTER 11 APN AMBR Traffic Policing 103

Revision History 103

Feature Description 103
Limitations 103
Configuring the APN AMBR Traffic Policing Feature 103
Monitoring and Troubleshooting 104
Show Commands and or Outputs 104

CHAPTER 12 APN Data Tunnel MTU Size Configuration 107

Revision History 107

Feature Description 107
Limitation 107
Configuring MTU 108

CHAPTER 13 App-based Tethering Detection in User Plane 109

Revision History 109

Feature Description 109
Limitation 110
Configuring App-based Tethering Detection 110
Enabling App-based Tethering Detection at Rulebase Level 110
Verifying App-based Tethering Detection at Ruledef Level 110
Monitoring and Troubleshooting the App-based Tethering Detection 111
Show Commands and Outputs 111

CHAPTER 14 APN and APN Profile-Based User Plane Selection for CUPS 113

Revision History 113

Feature Description 113

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
vii
 Cisco Confidential - Limited Release
Contents

How It Works 113

Architecture 115
Session Recovery and ICSR 115
Limitations 115
Licensing 115
Configuring APN-Based UP Grouping 116
Configuring User Plane Group in Control Plane 116
Configuring User Plane Group 116

Configuring Peer Node ID and User Plane Node IP Address 116

Verifying the User Plane Group 116

Associating User Plane Group with APN 117

Configuring User Plane Group in APN 117
Verifying the User Plane Group in APN 117

Method of Procedure (MOP) to Remove or Change User Plane Group from APN 117

Associating User Plane Group with APN Profile 118

Configuring User Plane Group in APN Profile 118
Monitoring and Troubleshooting APN-Based UP Grouping 118

CHAPTER 15 Cisco Ultra Traffic Optimization with VPP 119

Revision History 119
Feature Description 119
RCM Support 120
Sending the GBR or MBR Values to Cisco Ultra Traffic Optimization 120

Cisco Ultra Traffic Optimization Library Deinitialization 121

How it Works 121
Architecture 121
Limitations 122
Show Commands and Outputs 122
Show Commands and Outputs 122

Bulkstats 124
Sample Configuration 128

CHAPTER 16 Disable Radius Accounting 131

Revision History 131

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
viii
 Cisco Confidential - Limited Release
Contents

Feature Description 131

Configuring RADIUS Accounting on Dedicated Bearer Feature 132
Enabling RADIUS Accounting for All Bearers 132
Disabling RADIUS Accounting for a Specific Bearer 132
Enabling RADIUS Accounting only for the Default Bearer 133

CHAPTER 17 Default and Dedicated Bearer Support for Pure-P and Collapsed Sessions 135

Revision History 135

Feature Description 135
Supported Functionality 136
Limitations 137

CHAPTER 18 DSCP Markings For Collapse Calls 139

Feature Summary and Revision History 139

Feature Description 139
How It Works 140
Configuration 140
Monitoring and Troubleshooting 141
Show Commands Outputs 141
SMGR CP Changes 141

CHAPTER 19 Dynamic and ADC Charging Rule Names 145

Revision History 145

Feature Description 145

CHAPTER 20 Dynamic APN and IP Pool Support 147

Revision History 147

Feature Description 147
How It Works 147
Limitations 149
Configuring Dynamic APN and IP Pool Support 149
Updating the APN Configuration 150
Verifying Dynamic APN and IP Pool Support 150

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
ix
 Cisco Confidential - Limited Release
Contents

CHAPTER 21 Dynamic User Plane Selection 151

Revision History 151

Feature Description 151

CHAPTER 22 ECS Regular Expression Support 167

Feature Summary and Revision History 167

Feature Description 167
How It Works 168
Configuring Regex Rule 169
Configuring Regex Rule via RCM 170
Configuring Regex Rule via PFD Push 170

Sample Configuration 170

Monitoring and Troubleshooting 170
Show Commands and Outputs 170

CHAPTER 23 End Marker Packets 173

Revision History 173

Feature Description 173

CHAPTER 24 Enterprise Onboarding in CUPS 175

Feature Revision History 175

Feature Description 175
Operational Use Case 176
Architecture 176
Installation 176
How it Works 177
Pre-Processing 178
CP and UP Configuration 179
Post-Processing 180
Add Operation 181
Modify Operation 182
Delete Operation 182
Password Encryption 182

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
x
 Cisco Confidential - Limited Release
Contents

Onboarding Application – Usage and Input Parameters 184

CUPSinfo.txt 184
ADD_ENTERPRISE_INPUT_PARAMETERS.txt 186
MODIFY_ENTERPRISE_INPUT_PARAMETERS.txt 187
DELETE_ENTERPRISE_INPUT_PARAMETERS.txt 187
System Limits 187
Enterprise Onboarding in CUPS OAM Support 188
Show Commands 189
show cups-resource session summary 189
show ip user-plane verbose 189
Error Codes 189

CHAPTER 25 Event-based CDRs for CUPS 191

Revision History 191

Event-based CDRs for CUPS 191
Feature Description 191
How It Works 192
Fetching the Usage Report 192
Tariff Time 193
Event Trigger 193
Standards Compliance 194
Monitoring and Troubleshooting 194
Show Commands and/or Outputs 194
show active-charging subscribers full callid call_id urr-info 194

show subscribers user-plane-only callid call_id urr full all 194

CHAPTER 26 Event Data Records in CUPS 195

Revision History 195
Feature Description 196
TCP Fast Open 196
How It Works 196
Limitations 199
Configuring Event Data Records in CUPS 199
Configuration on CP to Push EDRs to UP 199

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xi
 Cisco Confidential - Limited Release
Contents

Configuration to Enable EDR Module on UP 200

Configuring Additional TCP Fields 200

Monitoring and Troubleshooting 200
show user-plane-service statistics rulebase name rulebase_name 200
show active-charging rulebase statistics real-time 201
show active-charging edr-format all 202
Bulks Statistics 202

CHAPTER 27 Error Indication and GTPU Path Failure Detection 203

Revision History 203

Feature Description 203
How It Works 204
Error Indication Support 204
Error Indication Handling at CP 204

Error Indication Handling on UP 204

Error Indication Generation on UP 205

Error Indication Call Flows 205

GTPU Path Failure Support 208

GTPU Path Failure Support at CP 208
GTPU Path Failure Support at UP 209

Limitations 210
Configuring Error Indication and GTPU Path Failure on Control Plane 210
Configuring Error Indication on CP 210

Configuring GTPU Path Failure on CP 211

Limitations 212

CHAPTER 28 Firewall Support in CUPS 213

Revision History 213
Feature Description 213
Overview 213
Configuring the Default Firewall Feature 214
Enabling Firewall for IPv4 and IPv6 215

Configuration Support for Subscriber Firewall 215

Monitoring and Troubleshooting 216

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xii
 Cisco Confidential - Limited Release
Contents

Show CLIs for CUPS 217

SNMP Traps 217
Reassembly Behavior Change 218

CHAPTER 29 Gx-alias Enhancement 219

Revision History 219

Feature Description 219
How it Works 219
Call Flow 220
Limitation 222

CHAPTER 30 Gy Multiple MSCC and FUI-Redirection 223

Revision History 223

Feature Description 223
Limitations 224

CHAPTER 31 Idle Timer for SAE-GW Sessions 225

Revision History 225

Feature Description 225
Limitations 225
Configuring Idle Timer for SAE-GW Sessions 226

CHAPTER 32 Indirect Forwarding Tunnel 227

Revision History 227

Feature Description 228
How It Works 228
Call Flow 228
Supported Functionality 228
Limitations 228
Configuring Indirect Forwarding Tunnel 229
Enabling Indirect Forwarding Tunnel Feature 229
Verifying the Indirect Forwarding Tunnel Feature 229
show sgw-service name <service_name> 229
Monitoring and Troubleshooting 229

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xiii
 Cisco Confidential - Limited Release
Contents

Show Commands Input and/or Outputs 229

show sub saegw-o full all 229
show sub user-plane-only callid <call-id> pdr all 230
show sub user-plane-only full all 230

CHAPTER 33 IP Pool Management 233

Revision History 233
Feature Description 234
How It Works 234
Handling UP De-Registration 234
Hold Timer 234
IP Pools per Context 236
IP Resource Management 236
IP Resource Replenishment/Withdrawal Procedure 237
No-chunk-pool for One UP per UP Group 237
Static IP Pool Management 238
UP Selection 238
Supported Functionality 239
Limitations 239
Configuring IP Pool Management 240
At Control Plane 240
Configuring Chunk-size Value 242
At User Plane 242
Configuring User Planes for a System 242
Monitoring and Troubleshooting 242
Show Command(s) and/or Outputs 242
show ip pool-chunks pool-name <pool-name> 243
show ip pool-chunks pool all 243
show ip pool-chunks up-id <up_id> user-plane-group name <grp-name> 243
show ip user-plane chunks 244
show ip user-plane prefixes 244
show ip user-plane verbose 245
show ip user-plane 246
show ipv6 pool-chunks pool-name <pool-name> 246

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xiv
 Cisco Confidential - Limited Release
Contents

show ipv6 pool-chunks up-id <up_id> user-plane-group name <grp-name> 247

CHAPTER 34 IP Source Violation 249

Revision History 249

Feature Description 249
Configuring IP Source Violation 249
Monitoring and Troubleshooting 250
Show Command(s) and/or Outputs 250
show sub user-plane-only full all 251

CHAPTER 35 L2 Marking Support 253

Revision History 253

Feature Description 253
How it Works 253
Limitations 255
Configuring L2 Marking Support 255
Configuring Internal Priority 255
Associating QCI-QoS Mapping Table 256

Configuring QCI Derived L2 Marking 256

Associating L2 Mapping Table 257
Configuring DSCP Derived L2 Marking 257

CHAPTER 36 L3, L4, and L7 Rule Combination in Ruledef 259

Revision History 259

Feature Description 259
How it Works 259
Configuring the L3, L4, and L7 Rule Combination in Ruledef Feature 260
Verifying the L3, L4, and L7 Rule Combination in Ruledef Feature Configuration 260
Monitoring and Troubleshooting 261
Show commands and Outputs 261

CHAPTER 37 L7 PCC Rules 263

Revision History 263

Feature Description 264

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xv
 Cisco Confidential - Limited Release
Contents

How It Works 264

Content Filtering 264
DNS 266
DNS Snooping 267
FTP 268
HTTP 268
HTTPS 271
HTTP URL Filtering 271
RTP/RTSP 274
RTP Dynamic Flow Detection 274
Rule-matching for Bearer-specific Filters 274
SIP 275

CHAPTER 38 Local Policy in CUPS 277

Revision History 277

Feature Description 277
How It Works 278
Configuring Local Policy in CUPS 278

CHAPTER 39 Load/Overload and UP Data Throttling Support on Sx 281

Feature Description 281

How It Works 281
User Plane Selection 281
Node-level Load/Overload Support 282

Sx Establishment Request Throttling at CP in Overload State 282

Sx Establishment Request Throttling at UP in Self-Protection 282
Session Termination Trigger from UP in Self-Protection 282
Limitation 283
Configuring Load and Overload Support 283

User Plane Load Control Profile Configuration 283

User Plane Overload Control Profile Configuration 284
Associating a Load Control Profile with a User Plane Service 286
Sx Protocol Configuration on Control Plane 286
Monitoring and Troubleshooting 287

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xvi
 Cisco Confidential - Limited Release
Contents

Show Commands Input and/or Outputs 287

show userplane-load-control-profile name name 287
show userplane-overload-control-profile name name 287
show user-plane-service statistics all 288
show sx service statistics all 289
Bulk Statistics 289
SNMP Traps 290

CHAPTER 40 LTE - Wi-Fi Seamless Handover in CUPS 291

Revision History 291

Feature Description 291
How It Works 292
LTE - Wi-Fi Handover 292
ICSR and Session Recovery 293
Limitations 293
Standards Compliance 293
Configuring LTE and Wi-Fi Seamless Handover 293
Monitoring and Troubleshooting 294
Show Command(s) and/or Outputs 294
show apn statistics name <name> 294

CHAPTER 41 Monitor Subscriber for CUPS 295

Revision History 295

Feature Description 295
Monitor Subscriber Sx Private IE 297
Control Plane SMGR Functionality 301
User Plane SMGR Functionality 301
Multi PDN Multi Trace 302
MonSub Stats 303
X-Header 303
How It Works 303
Configuration Procedure for Monitor Subscriber 303

Monsub CLI Options 304

Context, CDRMOD and Hexdump Interaction for Monitor Subscriber 306

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xvii
 Cisco Confidential - Limited Release
Contents

PCAP File Name Convention 306

PCAP File Location 309
Limitations 310
Configuring the Hexdump Module for MonSub in CUPS 311
Configuring MonSub Poll Timer 311
Configuring MonSub File Name 312
Monitoring and Troubleshooting 313
SNMP Traps 313

CHAPTER 42 MPLS Support on VPC-SI for CUPS 315

Revision History 315
Feature Description 315
How it Works 316
Monitoring and Troubleshooting 316
Show Command(s) and/or Outputs 316
show mpls fn vpp 316

CHAPTER 43 Multiple Control Plane Support on User Plane 317

Revision History 317
Feature Description 317
How it Works 318
Configuring Multiple Control Plane Support on User Plane 320
Disabling PFD Configuration Push from CP 320
Configuring Multiple CP on UP 320

Monitoring and Troubleshooting 320

Show Commands and/or Outputs 320
show sx-service statistics address <ip_address> 320
show user-plane-service statistics peer-address <ip_address> 323
Sample RCM Configuration 324

CHAPTER 44 N+2 UP Recovery 331

Revision History 331

Revision History 331
Feature Description 331

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xviii
 Cisco Confidential - Limited Release
Contents

Deployment Architecture 332

Limitations 332
How It Works 333
Call Flows 334
SAEGW Detach and Reattach on Path Failure 334
P-GW Detach and Reattach on Path Failure 336
S-GW Detach and Reattach on Path Failure 337
GnGp GGSN Detach and Reattach on Path Failure 339
Additional N+2 Handling Scenarios 341
Double Failure Handling Scenarios 345
BFD Flapping and VPC 345
Sx-association Scenarios 346
N+2 and IP Addressing 347
Loopback IP Addresses 347
IP Address Availability 347
Configuring N+2 UP Recovery 347
Monitoring and Troubleshooting 349
Show Commands 349
SNMP 349

CHAPTER 45 NAT Support 351

Feature Summary and Revision History 351
Revision History 351
Feature Description 351
Limitations 352
Configuring NAT in CUPS 353
Sample Configurations 353
Control Plane 353
User Plane 353
Monitoring and Troubleshooting 354
Gathering NAT Statistics in CUPS 354
Clear Commands 355
SNMP Traps for NAT Parameter Thresholds 355
Bulk Statistics 356

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xix
 Cisco Confidential - Limited Release
Contents

Context Schema 356

ECS Schema 357
NAT-realm Schema 358
EDRs 360
Sample EDR 360
NAT Binding Records 360
Sample NBR 361
Packet Drop EDR 361
Sample Packet Drop EDR 361

CHAPTER 46 NAT ALG Support 363

Feature Summary and Revision History 363

Revision History 363
Feature Description 363
Components of Session Initiation Protocol ALG 364

How it Works 366

FTP 367
RTSP 367
PPTP 367
SIP 367
TFTP 367
H323 368
NAT FW Processing 368
Uplink Packet Processing 369
Downlink Packet Processing 369
Configuring NAT ALG 369
Sample Configuration for FTP NAT ALG 370
Sample Configuration for RTSP NAT ALG 371
Sample Configuration for PPTP NAT ALG 371
Sample Configuration for TFTP NAT ALG 372
Sample Configuration for H323 NAT ALG 373
Sample Configuration for SIP NAT ALG 373
Monitoring and Troubleshooting 374

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xx
 Cisco Confidential - Limited Release
Contents

CHAPTER 47 N : M Redundancy 379

Revision History 379
Feature Description 379

CHAPTER 48 Netloc and RAN/NAS Cause Code 381

Revision History 381
Feature Description 381
Configuring Netloc and RAN/NAS Cause Code 381

CHAPTER 49 New Standard QCI Support 383

Revision History 383

Feature Description 383
Limitations 383

CHAPTER 50 Network Provided Location Indication 385

Revision History 385

Feature Description 385
How It Works 385
Supported Functionality 386
Limitations 386

CHAPTER 51 Nexthop Forwarding Support IPv4/v6 Address 387

Revision History 387

Feature Description 387
How It Works 387
Architecture 387
Configuring Nexthop Forwarding Support IPv4/IPv6 Address 391
Configuring Nexthop Forwarding at APN Configuration Mode 391
Configuring Nexthop Forwarding at IP Pool 391
Configuring Nexthop Forwarding Through AAA 391

Monitoring and Troubleshooting 392

Show Commands and Outputs 392

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxi
 Cisco Confidential - Limited Release
Contents

CHAPTER 52 Network Trigerred Service Restoration 393

Feature Description 393

Configuring NTSR 393
APN Profile Configuration 394
Peer Profile Configuration (Ingress) 394
NTSR Pool Configuration 394
S-GW Service Access Peer Map Association 395
Monitoring and Troubleshooting 395
Show Commands Input and/or Outputs 395
show apn-profile full all 395
show apn-profile full name apn_name 395
show ntsr-pool all 396
show ntsr-pool full all 396
show ntsr-pool full pool-id pool_id 396
show ntsr-pool pool-id pool_id 396
show sgw-service statistics all 396
show subscribers sgw-only full all 397

CHAPTER 53 NSH Traffic Steering 399

Revision History 399

Feature Description 399
Architecture 399
Components 400
Limitations 401
How it Works 402
Packet Flows 402
NSH Traffic Steering Requirements 405
SFP Selection 406
Configuring the L2 and NSH Traffic Steering Feature 407
N to M Traffic Steering 411
Interworking with Inline Features 416
Monitoring and Troubleshooting 416
SNMP Traps 422

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxii
 Cisco Confidential - Limited Release
Contents

Bulk Statistics 422

CHAPTER 54 Packet Flow Description Management Procedure for Static and Predefined Rules 425

Feature Description 425

How It Works 425
Moving Bulk Configurations from Control Plane to User Plane 426
Limitation 428
Sx Association 428
Configuring Control Plane Group 430

Monitoring and Troubleshooting Sx Association 433

Monitoring and Troubleshooting 435
Show Command(s) and/or Outputs 435
show user-plane-service charging-action all 436
show user-plane-service charging-action name charging-action-name 438
show user-plane-service rule-base all 439
show user-plane-service rule-base name rule-base-name 441
show user-plane-service rule-def all 443
show user-plane-service rule-def name rule-def-name 444

CHAPTER 55 PDI Optimization 445

Feature Summary and Revision History 445
Revision History 445
Feature Description 445
Relationships 446
How It Works 446
PDI Optimization Changes on Control Plane 446
Create Traffic Endpoint IE 447

Created Traffic Endpoint IE 448

Update Traffic Endpoint IE 448

Remove Traffic Endpoint IE 448

PDI Changes in Create PDR 449

PDI Optimization Changes on User Plane 449
Handling of Create Traffic Endpoint 449
Handling of Update Traffic Endpoint 449

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxiii
 Cisco Confidential - Limited Release
Contents

Handling of Remove Traffic Endpoint 449

Handling of Create PDR 450
Session Recovery and ICSR 450
Control Plane 450
User Plane 450
Standards Compliance 450
Limitations 451
Configuring the PDI Optimization Feature 451
Enabling PDI Optimization 451
Verifying the PDI Optimization Feature Configuration 452
PDI Optimization OAM Support 452
Show Command Support 452
show subscribers user-plane-only callid <call_id> pdr all 452
show subscribers user-plane-only callid <call_id> pdr full all 452

CHAPTER 56 P-GW CDR in CUPS 453

Revision History 453
Feature Description 453
Limitations 454
User Location Information in P-GW CDR 454

CHAPTER 57 P-GW Restart Notification 457

Revision History 457
Feature Description 457

CHAPTER 58 Post Processing Interaction for DCCA 459

Feature Description 459
Normal Rule Matching 459
Application Processing 460
Post Processing 460
Limit Reached Post Processing 461
Configuring Post Processing 461

CHAPTER 59 Priority Recovery Support for VoLTE Calls 463

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxiv
 Cisco Confidential - Limited Release
Contents

Feature Summary and Revision History 463

Feature Description 463
How It Works 463
Call Flows 465
Configuration 466
Monitoring and Troubleshooting 467
Show Commands and Outputs 467

CHAPTER 60 QoS Group of Ruledefs Support 469

Revision History 469

Feature Descriptions 469
How It Works 469

Data Path Enforcement 470

Static Configuration Push to UPlane 470
QGR Params Push to UPlane 470
Processing of QGR on UPlane 471
QGR Hit in Data Path 472
Limitations 472
Monitoring and Troubleshooting 472
Show Commands and Outputs 472

CHAPTER 61 Rate Limiting Function (RLF) 479

Revision History 479
Feature Description 479

CHAPTER 62 S2a Interface Support 481

Revision History 481
Feature Description 481

CHAPTER 63 S2b Interface Support 483

Feature Description 483

CHAPTER 64 S-GW CDR in CUPS 485

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxv
 Cisco Confidential - Limited Release
Contents

Revision History 485

Feature Description 485

CHAPTER 65 S-GW New Call Rejection 487

Feature Description 487
How It Works 487
Limitations 488
Configuring S-GW New Call Rejection 488
Enabling New Call Rejection 488
Monitoring and Troubleshooting 489
Show Command(s) and/or Outputs 489
show saegw-service statistics all function sgw 489

show sgw-service name 489

CHAPTER 66 S-GW Session Idle Timeout 491

Revision History 491

Feature Description 491
Configuring Session Idle Timeout 492

CHAPTER 67 SAEGW Idle Buffering with DDN Delay and DDN Throttling 493
Revision History 493
Feature Description 494
How It Works 494
Downlink Data Notification – Delay (DDN-D) Support 494
DDN Throttling Support 495
No User Connect Timer Support 496
DDN Call Flows 496
DDN Success Scenario 496
DDN Failure Scenario 497
No User Connect Timer Support 498
DDN Delay Timer 500
Sx Interface 501
Limitations 503
SAEGW Idle Buffering with DDN Delay and DDN Throttling Support Configuration 503

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxvi
 Cisco Confidential - Limited Release
Contents

DDN Throttling for Release 10 Compliant MME 503

DDN Throttling for non-Release 10 Compliant MME 504

Show Commands Input and/or Outputs 505

show subscribers user-plane-only-full all 505

CHAPTER 68 Self-overload Detection and Admission Control of Sx at UP 507

Revision History 507

Feature Description 507
Limitations 508
Configuring Overload Control at User Plane 508
eMPS Profile Creation and Association to S-GW and P-GW Services of Control Plane 508
Configuring the Overload Control Profile at UP 508

Configuring Overload Threshold Parameters 509

Configuring System Weightage Parameters 509
Configuring Session Manager Weightage Parameters 510
Associating an Overload Control Profile with a User Plane Service 510
Monitoring and Troubleshooting 510
Show Commands Input and/or Outputs 510
show user-plane-service name name 510
show user-plane-service statistics name user_plane_service_name 511
show userplane-overload-control-profile name name 511

CHAPTER 69 Smart Licensing 513

Revision History 513

Overview 513
Cisco Smart Software Manager 514
Smart Accounts/Virtual Accounts 514
Smart Licensing Mode 514
Request a Cisco Smart Account 515
Software Tags and Entitlement Tags 515

Configuring Smart Licensing 518

Monitoring and Troubleshooting Smart Licensing 519

CHAPTER 70 Static and Predefined Rule Match Support for Shallow Packet Inspection 521

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxvii
 Cisco Confidential - Limited Release
Contents

Revision History 521

Feature Description 521
How It Works 522
Monitoring and Troubleshooting 523
Show Command(s) and/or Outputs 523
show subscribers user-plane-only full all 523
show subscribers user-plane-only callid <callid> pdr full all 523
show subscribers user-plane-only seid <seid> pdr full all 524
show subscribers user-plane-only callid <callid> pdr id <id> 524
show subscribers user-plane-only seid <seid> pdr id <id> 524

CHAPTER 71 Static IP Assignment from RADIUS 525

Feature Description 525
How it Works 525
Limitations 525

CHAPTER 72 Suspend and Resume Notification for Pure-S Calls 527

Revision History 527

Feature Description 527
How It Works 527
Call Flows 528
Suspend Notification 528
Resume Notification 528

CHAPTER 73 Tariff Time Support 531

Revision History 531
Feature Description 531

CHAPTER 74 URL Blacklisting 533

Revision History 533

Feature Description 533
How it Works 533
Limitations 534
Configuring URL Blacklisting 535

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxviii
 Cisco Confidential - Limited Release
Contents

Loading URL Blacklisting Database on UP 535

Configuration to Enable URL Blacklisting 535

URL Blacklisting Database Upgrade 535
Monitoring and Troubleshooting 536
Show Command(s) and/or Outputs 536
show user-plane-service url-blacklisting database 536
show user-plane-service url-blacklisting database url database_directory_path 536
show user-plane-service url-blacklisting database facility sessmgr all 537

show user-plane-service inline-services info 537

show user-plane-service rulebase name rulebase_name 537

show user-plane-service inline-services url-blacklisting statistics 537
show user-plane-service inline-services url-blacklisting statistics rulebase name rulebase_name
538

Bulk Statistics 538

SNMP Traps 538

CHAPTER 75 User Plane Selection based on TAC Range 539

Revision History 539
Feature Description 539
How It Works 539
Limitations 540
Configuring User Plane Selection based on TAC Range 541
Configuring Tracking Area Code Range 541
Verifying the Tracking Area Code Range Configuration 541

CHAPTER 76 Virtual APN in CUPS 543

Revision History 543

Feature Description 543
How It Works 544
Limitations 544
Configuring Virtual APN in CUPS 544

CHAPTER 77 VoLTE Support in CUPS 547

Revision History 547

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxix
 Cisco Confidential - Limited Release
Contents

Feature Description 547

How It Works 548
Call Flows VoLTE Support 548
Handling Suspend Notifications 548
Handling Resume Notifications 549
Limitations 550

CHAPTER 78 Volume Reporting over Gx 551

Revision History 551

Feature Description 551
How it Works 552
Control Plane Handling for VoGx 552

User Plane Handling for VoGx 553

Limitations 553
Configuring VoGx Monitoring Key Range 553
Monitoring and Troubleshooting VoGx 554

Show Commands and/or Outputs 554

CHAPTER 79 VPN Manager Recovery Support 555

Feature Summary and Revision History 555

Feature Description 555

CHAPTER 80 VPP Support 557

Revision History 557
Charging Support 558
Delay-Charging via Rulebase 559
Flow Idle-time Out 559
HTTP Support 559
IP Readdressing 559
LTE Handover 560
Next Hop 560
PDN Update 560
Policing 561
Pure-S Support 562

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxx
 Cisco Confidential - Limited Release
Contents

Response-based Charging via Service Schema 562

Response-based TRM via Service Schema 562
ToS Marking 562
Volume-based Offload 563
Supported Functionality 563
Limitations 564
Enabling Fast Path in User Plane Service 564
Enabling VPP on SI Platform 564
Monitoring and Troubleshooting VPP Fast Path 565
Support for VPP Configuration Parameters Override 565

CHAPTER 81 VRF Support for CUPS 567

Revision History 567
Feature Description 567
Configuring VRF 568
Monitoring and Troubleshooting 571
Show Command(s) and/or Outputs 571
show ip chunks 571
show ipv6 chunks 571

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxxi
 Cisco Confidential - Limited Release
Contents

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
xxxii
 Cisco Confidential - Limited Release

CHAPTER 1
Overview
The Evolved Packet Core (EPC) network is evolving and moving toward Control User Plane Separation
(CUPS) based architecture where User Plane and Control Plane are separate nodes for P-GW, S-GW, and
TDF products. The User Plane and Control Plane combined together provide functionality of a node for other
elements in the EPC network. However, keeping it separate has numerous advantages from the network point
of view – support different scaling for Control Plane and User Plane, support more capacity on per session
level in User Plane, and so on.
This chapter highlights high-level details, call flows, and configurations related to Control Plane implementation
for P-GW, S-GW, and SAEGW products.
• Product Description, on page 1
• Supported Features and Functionality, on page 3
• How It Works, on page 12

Product Description
The SAEGW-U Virtualized Network Function (VNF) can be hosted in Cisco Ultra Services Platform (USP)
on COTS hardware or on ASR 5500/DPC2 chassis. The SAEGW-U can be collocated with SAEGW-C in the
same data center or can be located remotely in a different data center.
Following is a high-level architecture of User Plane as a service.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
1
 Cisco Confidential - Limited Release
Overview
Product Description

Some important points that describe the User Plane as a service:

• User Plane can be programmed from Control Plane.
• Single User Plane service can serve both SGW-U and P-GW-U type sessions.
• Two or more separate User Plane services can be defined for each node type, SGW-U and PGW-U,
respectively.
• A group of SAEGW-Us can be explicitly associated with an APN. If no group is associated, a default
group is used which includes all the registered User Planes that are registered to SAEGW-C but are not
part of any configured SAEGW-U group.
• User Plane service is associated with Sx service for the Control Plane interface, and GTP-U service for
receiving GTP-U packets.

Important Currently, each User Plane Service is associated with only single Sx service to
interface with Control Plane.

• User Plane service can be associated with four GTP-U services which can be extended to support SaMOG,
GGSN, and ePDG.
• Multiple peers of Control Plane services use single User Plane service.
• To associate the IP pool and its configuration, APN configuration is required.

Important Currently, User Plane supports APN and pool configuration. The IP addresses
are allocated from the Control Plane and are validated in the User Plane.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
2
 Cisco Confidential - Limited Release
Overview
Supported Features and Functionality

Supported Features and Functionality

3GPP ULI Enhanced Reporting Support
This feature enhancement covers ULI-related gaps in P-GW and GGSN as per 3GPP standards.
S4SGSN reports ULI to the P-GW through S-GW. P-GW determines the changes in the ULI with previously
received ULI. If P-GW detects any change and the change request is from the PCRF as an event trigger, then
the P-GW reports the ULI to the PCRF.
SGSN reports ULI to the GGSN. GGSN determines the changes in the ULI with previously received ULI. If
GGSN detects any change and the change request is from the PCRF as an event trigger, then the GGSN reports
the ULI to the PCRF. This feature also supports the detection of the change in RAI received as part of the
ULI field at GGSN.
For more information on 3GPP ULI Reporting Support Enhancement, refer the 3GPP ULI Reporting Support
Enhanced section in the StarOS P-GW Administration Guide.

AAA Server Group

The AAA Server Group feature is used to create and manage the Diameter/RADIUS server groups within the
context or system. The AAA server group facilitates management of group (list) of servers at per
subscriber/APN/realm-level for AAA functionality.

Note The AAA Server Group is an existing feature that is supported in non-CUPS architecture. With this release,
the feature is qualified in CUPS architecture.
For additional information about CLI configurations related to AAA server group, refer the AAA Server Group
Configuration Mode Commands chapter in the Command Line Interface Reference.

APN Configuration Support

Revision History

Revision Details Release

First introduced. 21.15.M0

The CLI commands radius-group, cc-home behaviour 0x10 profile 2 and mediation-device are qualified
and validated in the CUPS architecture to support APN configuration.

radius-group
Under this functionality validation the CUPS architecture supports 800 Radius Server Groups each group
configured with RADIUS Authentication and Accounting server.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
3
 Cisco Confidential - Limited Release
Overview
Asynchronous Core Transfer Support for egtpinmgr

cc-home { behavior bits | profile index }

Configures the home subscriber charging characteristics (CC) used by the GGSN when those from the SGSN
will not be accepted. The values configured in the CLI are taken into precedence by CUPS SAEGW service
and populated appropriately in the GTPP CDR records.
NOTES:
• behavior bits: Specifies the behavior bit for the home subscriber charging characteristic. bits can be
configured to any unique bit from 001H to FFFH (0001 to 1111 1111 1111 bin) where the least-significant
bit corresponds to B1 and the most-significant bit corresponds to B12.
• profile index: Specifies the profile index for the home subscriber charging characteristic. index can be
configured to any integer value between 0 and 15. Default: 8
• For more information, refer to the cc-home command under APN Configuration Mode Commands
chapter in the Command Line Interface Reference A-B document

mediation-device [ context-name context_name ] [ delay-GTP-response ] [ no-early-PDUs ] [ no interims ] +

This command and all associated sub section CLIs are supported in CUPS. This CLI enables use of mediation
device and all associated configuration that can be used for a given APN by CUPS SAEGW service.
NOTES:
• context-name context_name: Configures the mediation VPN context for this APN as an alphanumeric
string of 1 through 79 characters that is case sensitive. If not specified, the mediation context is the same
as the destination context of the subscriber. Default: The subscribers destination context.
• delay-GTP-response: When enabled, delays the CPC response until an Accounting Start response is
received from the mediation device. Default: Disabled.
• no-early-pdus: Specifies that the system delays PDUs from the MS until a response to the GGSN
accounting start request is received from the mediation device. The PDUs are queued, not discarded.
Default: Disabled.
• no-interim: Disables sending interims to the mediation server. Default: Disabled.
• For more information, refer to the mediation-device command under APN Configuration Mode Commands
chapter in the Command Line Interface Reference A-B document

Asynchronous Core Transfer Support for egtpinmgr

Asynchronous core transfer support for egtpinmgr has been added in CUPS to optimize outage time during
an egtpinmgr restart.
Previously, when the egtpinmgr restarted, the recovery process began only after a core dump file was created
and transferred. However, the time taken to transfer the core file was significant. The outage time during an
egtpinmgr restart was equal to the egtpinmgr recovery time plus the core file transfer time.
Support for Asynchronous Core Transfer has been added in CUPS to include the egtpinmgr during the recovery
process. Now, recovery begins when the egtpinmgr process crashes without waiting for the kernel to complete
a core dump file transfer and release its resources. As a result, the outage time during an egtpinmgr restart is
equal to the egtpinmgr recovery time only.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
4
 Cisco Confidential - Limited Release
Overview
Charging Data Records to HDD

With this enhancement, outage time during an egtpinmgr restart is reduced. The outage time consists only of
the time required to recover the egtpinmgr. The time taken to create and transfer the core file no longer
contributes to the outage time.

Note The Asynchronous Core Transfer Support for egtpinmgr is an existing feature that is supported in non-CUPS
architecture. With this release, the feature is qualified in CUPS architecture.

Charging Data Records to HDD

A Charging Data Record (CDR) is a formatted collection of information about a chargeable event. The GTPP
accounting CDRs that are generated are sent to an external node for storage. The CDRs are written to files in
formats supported by the external node and stored on the hard disk (HDD). From the HDD, CDR files can be
pushed/pulled using FTP/SFTP protocols.

Note The Charging Data Record (CDR) is an existing feature that is supported in non-CUPS architecture. With
this release, the feature is qualified in CUPS architecture. For additional information, refer the HDD Storage
chapter in the GTPP Interface Administration and Reference.

GTP-C Path Failure Enhancements and Improved Debugging Tools

In CUPS architecture, enhancements have been added to optimize GTP-C path failure functionality, and to
improve the debug capability of the system for GTP-C path failure problems. These features will help Operators
and Engineers to debug different aspects of the system that will help in identifying the root cause of GTP-C
path failures in the network. These enhancements affect path failure detection via the S5, S8, S2b, and S2a
interfaces.
The following enhancements are added in CUPS as part of this feature:
• The node can be configured so that it does not detect a path failure if a low restart counter is received
due to incorrect or spurious messages. This prevents call loss. The option to disable path failure due to
Echo Request/Response and Control Message Request/Response messages is also available so that call
loss is prevented in the event of a false path failure detection.
• More granularity has been added to GTP-C path failure statistics so that the root cause of issues in the
network can be diagnosed more quickly.
• A path failure history for the last five path failures per peer is available to assist in debugging path failures
in the network.
• Seamless path failure handling is implemented so that call loss is avoided during redundancy events.

Note The GTP-C Path Failure Enhancements and Improved Debugging Tools is an existing feature that is supported
in non-CUPS architecture. With this release, the feature is qualified in CUPS architecture. For additional
information, refer the GTP-C Path Failure Enhancements and Improved Debugging Tools section in the
P-GW Administration Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
5
 Cisco Confidential - Limited Release
Overview
Location Based DNS and PCSCF IP Address Selection

Location Based DNS and PCSCF IP Address Selection

Location-based DNS and P-CSCF Selection provides an option to the operator to manage the DNS server
address and P-CSCF IP address according to location information.
P-GW gathers the DNS server address and P-CSCF IP address information by Tracking Area Identifier (TAI),
which is achieved through the TAC-based Virtual APN (VAPN) selection.
When UE sends the PCO request in session creation, P-GW selects the Virtual APN (VAPN) with the received
location information. The selected VAPN (with DNS server address and P-CSCF IP address configured in it)
with PCO IE is sent in the Create session response.
Following are the CLI commands for enabling the Location-based DNS and PCSCF IP address selection:

Command Description
Tracking-area-code-range from <start Provides the tracking area code range, starting from 0 through
value> to <end value> 65536. The end value is always greater than the start value.
P-cscf priority <priority> ip/ipv6 Specifies the priority for P-CSCF address for the APN. Address_
<IPv4/Ipv6 address> priority is an integer 1–3. One is the maximum priority.
IPv4_address is in IPv4 dotted-decimal notation. IPv6_address is
in IPv6 colon-separated-hexadecimal notation.
Show apn name <APN Name> To show PCSCF IP address at APN
dns primary <IPv4 address> Primary: Configures the primary DNS server for the APN.
Dns secondary <IPv4 address> Secondary: Configures the secondary DNS server for the APN.
Only one secondary DNS server is configurable.
ipv6 dns primary <IPv6 address>
Address: Configures the IP address of the DNS server expressed
ipv6 dns secondary <IPv6 address>
in IPv4 dotted-decimal notation. Default: primary = 0.0.0.0,
secondary = 0.0.0.0
dns_address: Specifies the IP address of the DNS server to remove,
expressed in IPv4 dotted-decimal notation.

Show apn name <APN Name> To show DNS IP address at APN

MPRA Support
P-GW supports negotiation of Multiple-Presence Reporting Area feature in Feature-List-ID 2 over Gx interface
with PCRF. The CNO-ULI feature works only when the P-GW and/or the PCRF doesn’t support Multiple-PRA
and both P-GW and PCRF support CNO-ULI.
For Multiple-PRA feature support during the lifetime of the IP-CAN session, P-GW handles the change of
UE Presence in Reporting Areas request from PCRF in PRA-Install AVP including the
Presence-Reporting-Area-Information AVPs. Each AVP contains the Presence Reporting Area Identifier
within the Presence-Reporting-Area-Identifier AVP
For more information on Presence Reporting Area (PRA) and Multiple PRA, refer the Presence Reporting
Area chapter in the StarOS P-GW Administration Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
6
 Cisco Confidential - Limited Release
Overview
QUIC IETF Implementation

QUIC IETF Implementation

In the current framework, Deep Packet Inspection (DPI) is done for every packet in a flow when it reaches
the plugin. The DPI is done by analyzing the packets and extracting deterministic patterns. The DPI is done
in-order to detect the application and to classify its subtype. Plugin excludes the flow after the DPI. The flow
is offloaded after the detection. As part of QUIC IETF, the initial QUIC handshake packets (Client/Server
Hello) are encrypted over the network. Hence, there are no deterministic patterns available for detection of
the application. Support is added in p2p plugin to decrypt and obtain the SNI (Server Name Indication) for
detection.

Configuring QUIC IETF

Use the following configuration to enable or disable the QUIC IETF decryption.
configure
active-charging service acs_service_name
p2p-detection debug-param protocol-param p2p_quic_ietf_decrypt 1
end

Note By default, the CLI is disabled and there’s minimal impact on the performance due to TLS decryption.

Optimization for egtpinmgr Recovery

Previously, when the egtpinmgr task restarted, it took a significant amount of time for it to recover. As a result,
the outage time when the SAEGW were unable to accept any new calls during egtpinmgr recovery was high.
The software has been enhanced to optimize the recovery outage window in the event of an egtpinmgr task
restart; this has been achieved by optimizing the internal algorithms of egtpinmgr recovery and the data
structures required. In addition, recovery time now is dependent only on the number of unique IMSIs and not
on the number of sessions for an IMSI.

Note The Optimization for egtpinmgr Recovery is an existing feature that is supported in non-CUPS architecture.
With this release, the feature is qualified in CUPS architecture.

Quota Hold Time Support

Quota-Hold-Time (QHT) is an inactivity time duration, after which the Gateway(Diameter client) returns the
Charging-Bucket with its usage and reaches a clean-state.
The QHT value is provided by the OCS per Category - Multiple-Services-Credit-Control (MSCC), or the
gateway provides an option to configure the default value of the QHT - for enabling the default QHT value
for the MSCCs for which the OCS has not provided any QHT AVP.
The QHT timer runs per MSCC bucket. If the QHT timer expires without a packet during run-time, then the
usage is reported with the Reporting-Reason: QHT as per 3GPP specification.
The QHT value received in the CP from the OCS, is sent in the "Quota Holding Time" IE defined in the CUPS
specification 3GPP TS 29.244. Also along with provisioning the Quota-Holding-Time IE to the UP, the

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
7
 Cisco Confidential - Limited Release
Overview
S-GW Paging Enhancement

Reporting-Triggers will be sent with the bit corresponding to Quota-Holding-Time SET, so that on QHT
expiry the reporting takes place.
The UP on receiving the Quota-Holding-Time IE along with the QHT Reporting-Triggers enabled, starts the
timer per URR to monitor the inactivity period. Once the inactivity period exceeds the QHT time, the
Usage-Reporting is initiated from the UP for the Trigger : Quota-Holding-Time.
The CP on receiving the QHT event from UP, triggers the QHT reporting to the OCS after updating the usage
in the MSCC bucket.

Configuring Quota Hold Time

Use the following configuration to enable Quota Hold Time in CUPS:
configure
require active-charging
active-charging service service_name
credit-control group group_name
quota-hold-time timer_value
end
NOTES:
• quota-hold-time: configures the inactivity duration after which the charging bucket reports its usage
and have a clean state.

Limitation
The QHT (inactivity-timer) usually is a larger value compared to the flow-idle timer. If the flow-idle timer is
larger than QHT, then there is a possibility for the flows present even after the QHT expiry, and is processed
by VPP as per the NoQuota Pending-Traffic-Treatment configuration.

S-GW Paging Enhancement

S-GW Paging includes the following scenarios:
Scenario 1: S-GW sends a Downlink Data Notification (DDN) message to the MME/S4-SGSN nodes.
MME/S4-SGSN responds to the S-GW with a DDN Ack message. While waiting for the DDN Ack message
from the MME/S4-SGSN, if the S-GW receives a high priority downlink data, it does not resend a DDN to
the MME/S4-SGSN.
Scenario 2: If a DDN is sent to an MME/S4-SGSN and TAU/RAU MBR is received from another
MME/S4-SGSN, S-GW doesn't send DDN.
Scenario 3: DDN is sent to an MME/S4-SGSN and DDN Ack with Cause #110 is received. DDN Ack with
cause 110 is treated as DDN failure and standard DDN failure action procedure is initiated.
To handle these scenarios, the following two enhancements are added to the DDN functionality in CUPS
architecture:
• High Priority DDN at S-GW
• MBR-DDN Collision Handling

These enhancements support the following:

• Higher priority DDN on S-GW and SAEGW, which helps MME/S4-SGSN to prioritize paging.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
8
 Cisco Confidential - Limited Release
Overview
Session Recovery in User Plane

• Enhanced paging KPI and VoLTE services.

• DDN message and mobility procedure so that DDN isn't lost.
• MBR guard timer, which is started when DDN Ack with temporary HO is received. A CLI command
ddn temp-ho-rejection mbr-guard-timer has been introduced to enable the guard timer to wait for
MBR once the DDN Ack with cause #110 (Temporary Handover In Progress) is received.
• TAU/RAU with control node change triggered DDNs.

In addition, to be compliant with 3GPP standards, support has been enhanced for Downlink Data Notification
message and Mobility procedures. As a result, DDN message and downlink data which triggers DDN is not
lost. This helps improve paging KPI and VoLTE success rates in scenarios where DDN is initiated because
of SIP invite data.

Note For information on Downlink Data Notification (DDN) messages with support for DDN Delay and DDN
Throttling, refer the SAEGW Idle Buffering with DDN Delay and DDN Throttling chapter in this guide.
For more information on how S-GW Paging Enhancement feature works, configuration, monitoring and
troubleshooting, refer the S-GW Paging Enhancements chapter in the StarOS S-GW Administration Guide.

Session Recovery in User Plane

Support is added to recover the Session Manager process in the event of any crash. The recovered Session
Manager has all the existing subscriber session on the recently crashed Session Manager process.
Uplink and Downlink data flow is processed on the newly recovered Session Manager process for all recovered
subscriber sessions.

SRVCC PS to CS Handover Indication and the QoS Class Index IMS Media
Configuration Support
This feature notifies the PCRF about the cause for PCC rule deactivation on Voice bearer deletion. This
notification helps the PCRF to take further action appropriately.
This feature ensures the compliance for SRVCC. This feature also supports the PS-to-CS handover indication
after release of the voice bearers.
SRVCC service for LTE lets a single radio User Equipment (UE) accessing IMS-anchored voice call services
to switch from LTE network to Circuit Switched domain. The UE switches the network while it can transmit
or receive on only one of the access networks then. The SRVCC service removes the need for a UE to have
multiple Radio Access Technology (RAT) capabilities.
After handing over the PS sessions to the target, the source MME removes the Voice Bearers (VB). The MME
removes the VB by deactivating the voice bearers. The MME bars the VB towards S-GW/P-GW and sets the
VB flag of Bearer Flags IE in the Delete Bearer Command message (TS 29.274 v9.5.0).
If the IP-CAN bearer termination happens due to PS to CS handover. The PCEF reports the related PCC rules
for this IP-CAN bearer by including the Rule-Failure-Code AVP set to the value: PS_TO_CS_HANDOVER
(TS 29.212 v10.2.0 and TS 23.203 v10.3.0).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
9
 Cisco Confidential - Limited Release
Overview
SRVCC PS to CS Handover Indication and the QoS Class Index IMS Media Configuration Support

Support for new AVP PS-to-CS-Session-Continuity (added in 3GPP Release 11) inside Charging Rule Install
indicates the bearer support for PS to CS continuity.

QCI IMS-Media Configuration Support

Specifies the QoS Class Index (QCI) value to mark the IMS media bearers for preferential treatment during
session recovery and ICSR switchover.
Mode
Exec > Global Configuration > Context Configuration > APN Configuration
configure > context <context_name > apn <apn_name>
Entering the above command sequence results in the following prompt:
[context_name]host_name(config-apn)#
Syntax
qci value_bytes ims-media
no qci value_bytes ims-media

Note • no: Disables this IMS QCI feature.

• ims_media: Marks bearers classified as IMS media for preferential treatment during session recovery
and ICSR switchover.
• value_bytes: Specifies the QCI value an integer from 1 through 254.

Usage Guidelines Use this command to specify the QCI value to be used to mark bearers classified as IMS media for preferential
treatment during session recovery and ICSR switchover.
The following prerequisites apply to the implementation of this feature:
• A dedicated APN must be reserved for VoLTE traffic.
• A call connected to this APN will not be classified as Active VoLTE unless there is a dedicated bearer
matching the VoLTE-configured QCI.
• Preferential treatment would be given to only those calls which are active VoLTE.
• A GGSN call connected to this APN will not be classified as Active VoLTE unless there is network
initiated bearer matching the VoLTE-configured QCI.
• VoLTE marking is preserved across a Gn-Gp handoff.

When this feature is enabled via a CLI command, the actions are taken:
• During bearer creation
• New bearer QCI is matched against APN configuration.
• If the QCI matches an APN configuration, the bearer is marked for preferential treatment.
• Flow_entries are modified with this information (if this is first VoLTE bearer).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
10
 Cisco Confidential - Limited Release
Overview
Support for ip hide-service-address CLI Command

• Egtpu_session is updated with the VoLTE tag during a rx_setup request.

• An indication message informs ECS about the VoLTE tagging.

• During bearer deletion

• Flow_entry is updated with VoLTE information if this is the last VoLTE bearer.
• ECS is informed of the deletion via an indication message.

The following command enables preferential treatment for IMS bearers with a QCI of 9:
qci 9 ims-media

Support for ip hide-service-address CLI Command

The ip hide-service-address CLI command is supported in CUPS.
When enabled, this CLI renders the IP address of the GGSN unreachable from mobile stations (MSs) using
this APN. This command is configured on a per-APN basis.
Use the following configuration to enable or disable the feature.
configure
context context_name
apn apn_name
[ default | no ] ip hide-service-address
end
• default: Does not allow the mobile station to reach the GGSN IP address using this APN.
• no: Allows the mobile station to reach the GGSN IP address using this APN.
• Use this command to prevent subscribers from using traceroute to discover the network addresses that
are in the public domain and configured on services.

TFT Suppression for Default Bearer

Feature Description
TFT Suppression for default bearer is supported in the UPC CUPS architecture. Following CLI commands
are added in support of this feature.
• policy-control update-default-bearer
• no tft-notify-ue-def-bearer

The preceding CLI commands are used to bind all the predefined rules received from PCRF without QoS and
ARP or with the same QoS and ARP as that of the default bearer, to the default bearer.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
11
 Cisco Confidential - Limited Release
Overview
Configuring TFT Suppression

Important This CLI is applicable to all the rulebases in the chassis configuration. If the rulebase is changed to some other
rulebase in the interim period or anytime later, this CLI will continue to apply to the current new rulebase
too.

Configuring TFT Suppression

Configuring TFT Suppression in Default Bearer for Predefined Rules

Use the following commands to configure TFT Suppression for default bearers.
configure
require active-charging
require active-charging service_name
[ default | no ] policy-control update-default-bearer
end

Caution Upon executing this CLI command "no policy-control update-default-bearer", system crash is likely to
occur if the TFT information is not added to the charging-action.

Configuring TFT Suppression in Default Bearer

Use the following commands to configure TFT Suppression for default bearers.
configure
require active-charging
require active-charging service_name
rulebase rulebase_name
[ default | no ] tft-notify-ue-def-bearer
end

Note • default: Configures this command with its default setting.

Disables only binding those rules having QoS of default bearer to the default bearer and specifies to not
ignore other rules. Rules having respective QoS gets attached to the relevant bearers. Also, TFT updates
towards UE (access side) is not suppressed.
• no: Enables binding rules having QoS of default bearer to the default bearer and specifies to ignore other
rules.
In case no QoS is specified the rule gets attached to default bearer. Also, TFT updates towards UE (access
side) is suppressed for default bearer. So only one default-bearer is ever be created.

How It Works
This section describes the Call Flows for User Plane service.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
12
 Cisco Confidential - Limited Release
Overview
Call Flows

Call Flows
This section describes the User Plane Call Flows in the CUPS architecture.

P-GW Data Session

This section describes the P-GW initial attach procedure.

Initial Attach Procedure (Pure P)

Following call flow illustrates, at a high-level, the initial attach procedure for a Pure-P PDN.

• P-GW receives a Create Session Request message including an APN, on the S5/S8 interface.
• P-GW-C initiates an Sx establishment request on Sxb interface towards selected P-GW-U with PRDs,
FARs information to establish the data path. PGW-C does not support TEID (Tunnel Identifier) allocation;
it is allocated by PGW-U.
• Once the resources are allocated (TEID and so on), P-GW-U sends an Sx establish response message
towards P-GW-C.
• P-GW responds to the S-GW with a Create Session Response message including the assigned address,
TEID, and additional information.
• The S5/S8 data plane tunnel is established and the PGW-U can forward and receive packets to and from
the PDN.

Initial Detach Procedure (Pure P)

Following call flow illustrates, at a high-level, the initial detach procedure for a Pure-P PDN.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
13
 Cisco Confidential - Limited Release
Overview
S-GW Data Session

• P-GW receives a Create Session Request message including an APN, on the S5/S8 interface.
• P-GW-C initiates an Sx establishment request on Sxb interface towards selected P-GW-U with PRDs,
FARs information to establish the data path. PGW-C does not support TEID (Tunnel Identifier) allocation;
it is allocated by PGW-U.
• Once the resources are allocated (TEID and so on), P-GW-U sends an Sx establish response message
towards P-GW-C.
• P-GW responds to the S-GW with a Create Session Response message including the assigned address,
TEID, and additional information.
• The S5/S8 data plane tunnel is established and the PGW-U can forward and receive packets to and from
the PDN.

S-GW Data Session

This section describes the S-GW initial attach procedure.

Initial Attach Procedure (Pure S)

Following call flow illustrates, at a high-level, the initial attach procedure for a Pure-S PDN.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
14
 Cisco Confidential - Limited Release
Overview
Initial Attach Procedure (Pure S)

• On S11 interface, S-GW-C receives a Create Session Request message including an Access Point Name
(APN) from MME.
• S-GW-C initiated the Sx establishment request on the Sxa interface towards the selected S-GW-U with
PDRs, FARs information to establish data path. Here, the S-GW-C does not support the TEID (Tunnel
Identifier) allocation. It is allocated by the S-GW-U.
• After allocation of resources such as egree TEID and so on, S-GW-U sends the Sx establishment response
message towards the S-GW-C.
• The S-GW-C initiates the Create Session Request towards the selected P-GW-C.
• P-GW-C responds with the Create Session Response with the IP address and default bearer related
information.
• SGW-C initiates Sx Modification Request message towards SGW-U to update FAR (Forwarding action)
information for the existing session.
• SGW-U provides Sx Modification Response with success after updating information.
• SGW-C sends Create Session Response with all necessary information for Default Bearer towards MME.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
15
 Cisco Confidential - Limited Release
Overview
Initial Detach Procedure (Pure S)

• MME initiates Modify Bearer Request message towards SGW-C, once it received eNodeB's F-TEID
information.
• SGW-C initiates Sx Modification Request towards SGW-U for updating FAR information on eNodeB's
F-TEID.
• After successfully updating, Sx Modification Response is sent to SGW-C.
• SGW-C inturn will send Modification Response message towards MME to complete attach procedure.
• SGW-U has established S1U side data tunnel towards eNodeB and S5/S8 side data tunnel towards
PGW-U. Now, SGW-U can forward and receive packets to/from PGW as well eNodeB.
• The S5/S8 data plane tunnel is established and the PGW-U can forward and receive packets to/from the
PDN.

Initial Detach Procedure (Pure S)

Following call flow illustrates, at a high-level, the initial detach procedure for a Pure-S PDN.

• Once Delete Session Request is received from MME, SGW initiate Sx Delete Request message towards
SGW-U.
• SGW-U clears all allocated User-Plane resources and responds back with Cause Success to SGW-C.
• SGW-C responds back to MME with Delete Session Response message.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
16
 Cisco Confidential - Limited Release
Overview
Support for Addition, Deletion and Updation of Dedicated Bearers for S-GW

Support for Addition, Deletion and Updation of Dedicated Bearers for S-GW
Feature Description
Addition, Deletion and Updation of Dedicated Bearers for Pure-S calls is supported in the CUPS architecture.
The following functionality is added in support of this feature:
• SAEGW-CP supports Create Bearer Request for dedicated bearer for Pure-S Call.
• SAEGW -CP supports multiple bearer contexts in single Create Bearer Request.
• SAEGW-CP supports multiple Create Bearer request in parallel for different PDN; these PDN can be
Pure-S PDN or Collapsed and Pure-S combinations.
• SAEGW-UP creates uplink and downlink bearer stream at VPP for Pure-S call per bearer. Number of
streams per direction depends on the GTP-U Service IP address.
• SAEGW-CP supports Release Access Bearer Request (RAB) with dedicated bearer, all FAR corresponding
to all bearer is modified.
• SAEGW-CP supports Modify Bearer Request (Idle mode, Connected mode) with dedicated bearer.
• SAEGW-CP supports Create Bearer Response Failure handling from MME.
• SAEGW-CP and SAEGW-UP supports DSCP marking for default and dedicated bearer with VPP.
• SAEGW-CP and SAEGW-UP supports Delete Bearer Request for dedicated bearer. SAEGW-UP removes
bearer stream and TEP entries belonging to those bearers.
• SAEGW-CP supports Pure-S Dedicated Bearer Creation when call is in IDLE state.
• SAEGW-CP supports Pure-S Dedicated Bearer S-GW Relocation (both X2 and S1-based).
• SAEGW-CP supports Pure-S Dedicated Bearer Update success scenarios.
• SAEGW-CP supports Piggybacking of Create Bearer Request for dedicated bearer for Pure-S call along
with Create Session Response.
• SAEGW-CP supports Piggybacking of Create Bearer Response for dedicated bearer for Pure-S call with
Modify Bearer Request.
• SAEGW-CP supports Pure-S Dedicated Bearer Creation if P-GW receives bearer creation as part of
CCA-I, where P-GW does not send Piggyback request, which results in Create Session Response followed
by Create Bearer Request.
• SAEGW-CP supports Session Recovery and ICSR with Pure-S dedicated bearer.
• SAEGW-CP supports Create Bearer Request and Delete Bearer Request (default bearer) collision.
• SAEGW-CP supports Create Bearer Request and Delete Session Request collision.
• SAEGW-CP supports Create Bearer Response and Delete Bearer Request (default bearer) collision.
• SAEGW-CP supports Create Bearer Response and Delete Session Request collision.
• SAEGW-CP supports End Marker with Pure-S default and dedicated bearer.
• SAEGW-UP supports Session Recovery with Pure-S default and dedicated bearer.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
17
 Cisco Confidential - Limited Release
Overview
Limitations

• SAEGW-UP supports movement of IP transport from IPv4 to IPv6, or IPv6 to IPv4, during IDLE->Active
and Handover procedure on S1U interface. Transport selected on S1U at the time of Attach is supported.
For example, eNode handover from IPv4 eNodeB to IPv6 eNodeB will work.
• SAEGW-CP supports CBRsp with Cause Partially Accepted and Context Not Found.
• SAEGW-CP supports Downlink Data Notification for Pure-S Call, so when UE moves to IDLE state for
Pure-S call, FAR action is set as BUFFER.
• SAEGW-CP supports Update Bearer Response with cause PARTIALLY_ACCEPTED and context not
Found.
• SAEGW-CP supports the Error and Failure handling from other peer nodes including User Plane node.

Limitations
For Pure-S calls, Idle Session timeout is not supported.

Support for Collapse Call

Following call flow illustrates, at a high-level, the detach procedure for UE initiated Collapsed PDN.

Initial Attach Procedure (Collapsed PDN)

The following call flow illustrates, at a high-level, the initial attach procedure for Collapsed PDN.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
18
 Cisco Confidential - Limited Release
Overview
Initial Attach Procedure (Collapsed PDN)

1. For CUPS SAEGW collapsed call, SAEGW-C does the following:

• After Gx interaction, performs Gx communication (CCR-I and CCA-I).
• Performs User Plane selection based on user-plane-profile configured with IP Pool (APN associated
with IP Pool).
• Establishes GTP-U session (required for RA/RS, in case of IPv6/IPv4v6 PDN).
• Performs Sxab interaction with selected User Plane.

2. Sx Establishment Request contains the following information:

• Create PDR/FAR information for S-GW Uplink and Downlink data path (Sxa Type PDR).
• Create PDR/FAR/URR information for Uplink and Downlink data path (Sxb Type PDR): For
dynamic/pre-defined/static rules.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
19
 Cisco Confidential - Limited Release
Overview
Initial Detach Procedure (Collapsed Call)

• Create PDR/FAR for RA/RS (Sxb Type PDR): Required for IPv6/IPv4v6 PDN Type.

• Additionally, Control Plane requests User Plane to allocate F-TEID for:

• S-GW Ingress "S1-U S-GW F-TEID",
• S-GW Egress "S5/S8-U S-GW F-TEID", and
• P-GW Ingress PDR "S5/S8-U P-GW F-TEID"

3. User Plane provides following information as part of Sx Session Establishment Response:

• Created PDR: S-GW Ingress PDR "S1-U S-GW F-TEID",
• Created PDR: S-GW Egress PDR "S5/S8-U S-GW F-TEID", and
• Created PDR: P-GW Ingress PDR "S5/S8-U P-GW F-TEID"

4. On receipt of successful Sx Session Establishment Response, the Control Plane triggers Sx Modification
Request with the following information:
• To update P-GW (Sxb) "Uplink PDR" with "Outer Header Removal" based on IP address information
in "S5/S8-U S-GW F-TEID"
• To update P-GW (Sxb) "Downlink FAR" with "Outer Header Creation" as "S5/S8-U S-GW F-TEID"
• To update S-GW (Sxa) "Uplink FAR" with "Outer Header Creation" as "S5/S8-U P-GW F-TEID"
• To update S-GW (Sxa) "Downlink PDR" with "Outer Header Removal" based on IP address
information in "S5/S8-U P-GW F-TEID"

5. On receipt of Sx Session Modification Response, the SAEGW-C sends Create Session Response toward
MME with "S1-U S-GW F-TEID" and "S5/S8-U P-GW F-TEID".
6. On receipt of Modify Bearer Request (MBR), the SAEGW-C does the following:
• Trigger Sx Session Modification Request:
• To update Downlink FAR with "Outer Header Creation" as "S1 eNodeB F-TEID".
• To update Uplink PDR with "Outer Header Removal" based on IP address information in "S1
eNodeB F-TEID".

7. On receipt of Sx Session Modification Response, the SAEGW-SGW-C sends MBR with "S1-U S-GW
F-TEID".

Initial Detach Procedure (Collapsed Call)

Detach Procedure (Collapsed): UE Initiated

Following call flow illustrates, at a high-level, the detach procedure for UE initiated Collapsed PDN.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
20
 Cisco Confidential - Limited Release
Overview
Detach Procedure (Collapsed): Network Initiated

1. On receipt of Delete Session Request, the SAEGW-C performs Sxab interaction to update FAR with
Apply Action as "DROP" for both Uplink and Downlink data path.
2. On receipt of Sx Session modification Response, SAEGW-C sends Delete Session Response towards
MME.
3. For CUPS SAEGW Collapsed call, the SAEGW-C does the following:
• Removes GTP-U session (required for RA/RS in case of IPv6/IPv4v6 PDN).
• Performs Sxab interaction with the selected User Plane.

4. On receipt of Sx Session Deletion Response, the SAEGW-C does the following:

• Performs Gx communication (CCR-T and CCA-T).
• Generates CDR (Gz) based on URR information received.

Detach Procedure (Collapsed): Network Initiated

Following call flow illustrates, at a high-level, the detach procedure for network initiated Collapsed PDN.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
21
 Cisco Confidential - Limited Release
Overview
P-GW Session Reporting with Gy Interface

1. On receipt of Delete Bearer Request (RAR initiated or by the clear sub all CLI), SAEGW-C performs
Sxab interaction to update FAR with Apply Action as "DROP" for both Uplink and Downlink data path.
2. On receipt of Sx Session Modification Response, SAEGW-C sends Delete Bearer Request toward MME.
3. For CUPS SAEGW Collapsed call, the SAEGW-C does the following:
• Removes GTP-U session (required for RA/RS in case of IPv6/IPv4v6 PDN).
• Performs Sxab interaction with the selected User Plane.

4. On receipt of Sx Session Deletion Response, the SAEGW-C does the following:

• Performs Gx communication (CCR-T and CCA-T).
• Generates CDR (Gz) based on URR information received.

P-GW Session Reporting with Gy Interface

This section describes P-GW session reporting with Gy interface.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
22
 Cisco Confidential - Limited Release
Overview
URR Support in Session Establishment Request

URR Support in Session Establishment Request

• User plane module supports the storage of a list of URRs received as part of session establishment request.
• Each PDR is associated with one or more URRs.
• A particular URR is linked to another URR.
• Each URR contains the measurement method (time or volume), and reporting triggers that indicates the
event on which the user plane has to send usage report.
• The URR have both volume-quota and volume-threshold present for the Gy-URRs.

Session Delete Response

This message sent from the User Plane is in response to a session deletion request from control plane. This
results in the termination of the Sx session at User plane. Usage Report is included as part of Sx Delete Session
Response.

Session Report Request and Response Message

Request Message
• On encountering a time or volume threshold limit, user plane generates an Sx Session Report Request
message and sends the same to control plane.
• This message contains the Usage report, which indicates the reason for generating the message, specified
by Usage Report Trigger.
• In addition to this, the Usage report contains the time or volume measurement.
• If any other URRs are linked to the URR for which the session report request is being generated, then a
session report request is generated for those linked URRs as well. For this release, Gy-URRs are not
linked with any of the URRs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
23
 Cisco Confidential - Limited Release
Overview
Response Message

Response Message
This message from the Control plane indicates a successful delivery of the Session Report Request message
with a cause code. Currently no specific failure handling is done on receiving a failure cause.

Server-Unreachable Support for Gy

The Server-Unreachable (SU) mechanism is configured on the Control-Plane (CP), for the Gy interface in
order to resolve issues that are encountered on the Online Charging System (OCS) or with the connectivity
between Policy and Charging Enforcement Function (PCEF) and OCS. The SU configuration provides the
options to continue the session even after a failure by providing the option to use configurable interim quota
(volume and/or time) and configurable server retries before a session is converted to offline or terminated.
A new Usage Reporting Rule (URR) bucket is created, which contains the SU quota when a Gy session goes
into the SU state. The ID for the new URR is generated dynamically when the SU URR is allocated.
In a CUPS User Plane (UP) node, the existing Vector Packet Processor (VPP) streams are modified with a
new LC record, which contains the updated SU URR bucket along with the existing set of charging buckets.
When the VPP streams are in the SU state, two quota rows are available, GyURR and SU URR. When GyURR
is in the SU state with linked-usage-reporting trigger set, the quota row for the SU URR is linked to the VPP
streams.
This section describes the SU call flow in CUPS.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
24
 Cisco Confidential - Limited Release
Overview
Server-Unreachable Support for Gy

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
25
 Cisco Confidential - Limited Release
Overview
Server-Unreachable Support for Gy

Step Description
1 PGW-U sends a Sx Session Report Request message
with URR1 (RG-1) to PGW-C due to internal triggers
like Time and Volume or Quota and Threshold.
2 PGW-C acknowledges the request and sends a Sx
Session Report Response message to PGW-U.
3 PGW-C sends CCR Update (CCR-U) Request
message to both the primary and secondary OCS.
4 When the CCR-U Request messages fail at both
primary and secondary OCS, the Gy session enters
an SU state. The SU URR is created for the Gy
session, and it’s linked to the relevant PDRs. PGW-C
sends an Sx Session Modification Request message
to PGW-U with UpdatePDR, which includes Gy SU
URR in the PDR URR list.
5 PGW-U starts updating the usage in both the Gy
buckets (URR1 and Gy SU URR1) and sends an Sx
Session Modification Response message to PGW-C.
6 PGW-U sends another Sx Session Report Request
message with URR2 (RG-2) to PGW-C after the Gy
URR bucket exhausts the quota .
7 PGW-C acknowledges the request sends a Sx Session
Report Response message to PGW-U.
8 PGW-C sends an Sx Session Modification Request
message to PGW-U with UpdatePDR and Update
RR2. The UpdatePDR has a modified URR list, which
contains both URR2 and Gy SU URR.
9 PGW-U sends an Sx Session Modification Response
message to PGW-C.
10 PGW-U sends a Sx Session Report Request message
with URR1 (RG-1) and URR2 (RG-2) to PGW-C
after the Gy SU URR quota is exhausted.
11 PGW-C acknowledges the request and sends a Sx
Session Report Response.
12 PGW-C sends CCR Update (CCR-U) Request
message to OCS after an SU retry.
13 OCS sends a CCA Update Response message with
the Result-Code as 2001.

14 PGW-C sends an Sx Modification Request message

with URR1 (RG-1), URR2 (RG-2), and UpdatePDR
(without Gy SU URR) to PGW-U.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
26
 Cisco Confidential - Limited Release
Overview
Limit-Reached Postprocessing

New Behavior in CUPS

The new SU mechanism in CUPS, are as follows:
• In a non CUPS architecture, where a single node (P-GW) processes the Gy session state and the data-traffic,
an SU URR is created without any messaging delay. However, in the CUPS mode, the CP forms an
additional node, which maintains information about the session state and handles any URR requests from
the User Plane (UP). Only the CP can associate a Gy session with an SU URR. This messaging between
UP and CP causes a delay and the data packets are treated according to the Pending-Traffic-Treatment
configuration to complete the communication.
• In a non CUPS architecture, the SU state timer is processed in a different manner compared to the
Time-Quota timer. After an SU quota is exhausted, the retry attempt to OCS occurs and a new
next-interim-time-quota is started. However, in the CUPS mode, when the SU Time Quota is used and
it is reported to CP for the Quota Exhaust, and if the session goes into Server-Unreachable state again,
the time elapsed from the last Usage-Report is accounted in the usage.

Limit-Reached Postprocessing
Limit-reached-post-processing is a non-3GPP, proprietary behavior supported in both CUPS and non-CUPS
architecture. This feature allows redirection or restriction operation implemented when the quota is exhausted
for the charging-bucket, however, the OCS server is unable to grant the FUI-Redirect or FUI-Restrict. When
using this feature, the operator can combine all the rule-matching criteria that are available—for example, to
enable IMSI-based matching criteria, and so on—to selectively apply different handling for different
subscribers/traffic. Use the following CLI commands to enable the feature.
configure
active-charging service service_name
rulebase rulebase_name
post-processing policy always
end
Also, rule-application post-processing CLI command must be configured as limit-reached under ACS
Ruledef configuration mode.

PTT no-quota Limited Pass

This feature allows the subscriber to use the network while waiting for the response from OCS. The
Limited-Pass configuration allows to specify the Volume which the subscriber can consume while waiting
for the quota-response from OCS. The usage is accounted in the respective charging bucket and are adjusted
against the next-quota allocation.
Use the following CLI commands to enable the feature:
configure
active-charging service service_name
credit-control
pending-traffic-treatment noquota limited-pass volume volume
end
Limited Pass Volume is used only for noquota case (Rating Group (RG) seeking quota for the first time) and
not for quota-exhausted. Limited Pass Volume isn't used for subsequent credit requests.
The traffic is allowed to pass until the Limited-Pass Volume gets exhausted. The usage is counted in the
respected charging-bucket and adjusted against the "Quota" granted. If the "Quota" allocation is less than the

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
27
 Cisco Confidential - Limited Release
Overview
PTT quota exhaust Limited Pass

actual usage, immediate reporting towards OCS with the usage-report occurs requesting for more quota
allocation. The subsequent incoming packets are handled as per the "quota-exhausted" PTT configuration.
If the Limited Pass Volume is NOT exhausted before the OCS responds with denial of quota, traffic is blocked
after the OCS response. The gateway reports usage on Limited-Pass Volume even in for CCR-U (FINAL)
(in non-CUPS) or CCR-T (for CUPS) until the OCS responds.
If the Limited Pass Volume is exhausted before the OCS responds, then the subsequent incoming packets for
the session are dropped until quota is granted from OCS.
The default pending-traffic-treatment for noquota is Drop. The default pending-traffic-treatment noquota
command removes any Limited Pass Volume size configured.

PTT quota exhaust Limited Pass

Pending-Traffic-Treatment (PTT) Quota-Exhausted Limited-Pass in the CUPS mode is an alternative to the
Buffering option. The requirement for the buffering has some practical limitations in the high-speed network.
Buffering requires packet buffering for large number of packets at the gateway. The large number of packets
can result in risking to run-out of memory affecting the bandwidth speed. So, PTT quota exhaust is an alternate
to the Buffer option. The PTT quota exhausted limited pass allows the traffic to pass through until the configured
limit on the Quota-Exhaust scenarios.
Use the following CLI command to enable the feature:
configure
active-charging service service_name
credit-control
pending-traffic-treatment quota-exhausted limited-pass volumevolume

end

Note The above CLI is only applicable for the CUPS architecture.

After the Limited-Pass volume exhausts, the further packets drop until the quota allocation comes.
The PTT allows the traffic until the Limited-Pass volume exhausts. The PTT counts and adjusts the usage in
the respected charging-bucket against the "Quota" granted. If the "Quota" allocation is less than the actual
usage, there’s immediate reporting towards OCS with the usage-report and asking for more quota allocation.
If the limited pass volume doesn’t exhaust before the OCS responds with denial of quota, there’s traffic
blockage after the OCS response. Gateway reports the usage in CCR-U (FINAL).
If the limited pass volume exhausts before the OCS responds, then further incoming packets for the session
drop until grant quota from OCS.
The default pending-traffic-treatment for quota-exhausted is drop. The default pending-traffic-treatment
quota-exhausted command removes any Limited Pass Volume size configured.

Quota-Validity-Time Handling
When the Quota-Validity-Time is received for an MSCC bucket, the same is sent to the User Plane. Since
there is no specific IE that can be used directly, the QVT value is filled in the Time-Quota IE, and URR is
sent to the User Plane. The lesser QVT or Time-Quota is set in the Time-Quota IE. And, the Usage-Reporting
from the User Plane for the Time-Quota trigger, the interpretation is made and the CCR-Update for the
Validity-Timeout is generated.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
28
 Cisco Confidential - Limited Release
Overview
Supported Functionality and Limitations

Supported Functionality and Limitations

Basic call flow with Volume-Quota mechanism is supported with the following limitations on P-GW session
reporting for Gy interface:
• Only CCR/CCA-I , CCR/CCA-U and CCR/CCA-T, RAR/RAA messages are supported.
• Dynamic Rules with Online Enabled is supported; both at Session-Setup and Mid-Session.
• Predefined Rules (dynamic-only) is supported; both at Session-Setup and Mid-Session. No restriction
on configuring the "preemptively request".
• Static-rules with Online Charging are supported.
• Ignore-service-id is supported.
• Volume-Quota/Volume-Threshold mechanisms are supported.
• Event-Triggers (through which the Query URR occurs), and sending of usage information to the OCS
is supported.

Important RAT-change functionality is not validated for this release.

• The "updateURR" procedure, through the Sx-Session-Modification procedure where the OCS grants a
fresh Quota, is supported.
• Bearer-Level Gy and Subscriber-Level Gy is supported.
• Pending-Traffic-Treatment (PTT) Drop/Pass is supported with following limitations:
• The scenarios supported for now are no-quota and quota-exhausted.
• The trigger/re-authorization scenarios are not supported.
• The PTT action (Forward/Drop) is considered after the quota-get is exhausted.

• Failure scenarios are qualified, which includes:

• Failure-Handling Terminate, Continue and Retry, and Terminate: With CC-Group/FHT
• Handling for the Error-Result-Codes (both at MSCC and Command level) is supported.

• Wall-Clock time-quota mechanism is supported.

• Other Time Quota Mechanisms (Discrete Time Period and Continuous-Time-Period) are not supported.
• Final-Unit-Indication Terminate mechanism is supported.
• FUI-Restrict is not supported.
• Mid-Session Rule Installation/Removal/Modification is supported.
• RAR mechanism is supported.
• Server-Unreachable (SU) mechanism is now supported with minor change in behavior compared to
non-CUPS P-GW.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
29
 Cisco Confidential - Limited Release
Overview
Supported Functionality and Limitations

• When an URR needs quota at UP, the usage-report is generated to CP and until the CP responds
with the linked SU_URR, the packets matching this URR are treated with Pending-Traffic-Treatment
configuration.
• When the SU Time Quota is used and it's reported to CP for the Quota Exhaust, and if the session
goes into Server-Unreachable state again, the time elapsed from the last Usage-Report is accounted
in the usage.

• Pending-Traffic-Treatment Buffer mechanism is not supported.

• The “send-ccri on traffic-start” is supported.
• Quota-Hold-Time is supported.
• Quota-Consumption-Time mechanism is not supported.
• Quota-Validity-Time is supported.
• Triggering Gz records from Gy, when any event in Gy occurs, is supported; Gy-Gz sync is not supported.
• Triggering Rf records from Gy, when any event in Gy occurs, is not supported.
• Configuring different "rating-group" value other than the "content-id" is supported.
• The RG 0 is not supported.

• Trigger to PCRF for the Out-of-Credit, Reallocation-of-Credit events are not qualified.

Important Event-trigger Out-of-Credit towards PCRF is validated with a limitation of having

only one time Grant-Quota (Keeping Total Volume and Granted Volume at same
value).

• The delayed response from OCS for the CCR-I is supported.

• Service-Specific-Units are not supported.
• Tariff-Time change is supported as per 3GPP specification.
• Quota-Retry Timer is supported.
• The diameter mscc-final-unit-action terminate session CLI command under Credit Control
Configuration mode is supported.
• FUI-Redirect is supported with following limitations:
• Redirection for HTTPs is not supported.
• The FUI-Redirect with Filter-IDs/Filter-Rules are not supported.
• The WSP Protocol is not supported.
• In accordance with 3GPP specification, the Redirected-Traffic also gets redirected if it hits the rule
that is in FUI-Redirect. There is no provision to allow the redirected-traffic to pass through.
• In accordance with 3GPP specification, the CUPS architecture adheres to no diameter
fui-redirected-flow allow CLI command behavior.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
30
 Cisco Confidential - Limited Release
Overview
P-GW Session Reporting with Gz Interface

• The redirect-require-user-agent CLI command is not supported; the redirection continues to work
even if the user-agent is not present.
• Appending the original URL is not supported.
• The diameter redirect-validity-timer immediate CLI command is supported. However, diameter
redirect-validity-timer traffic-start CLI command is not supported.
• Token based mechanism, to come out of Redirection, is not supported. To end the redirection in
CUPS, OCS sends Redirect Validity-Time or RAR.
• FUI-Redirection is supported only for the URL, similar to the behavior in non-CUPS architecture.

• Rulebase change from PCRF/OCS is supported.

P-GW Session Reporting with Gz Interface

This section describes P-GW session reporting with Gz interface.

URR Support in Session Establishment Request

• User plane module supports the storage of a list of URRs received as part of session establishment request.
• Each PDR is associated with one or more URRs.
• A particular URR is linked to another URR.
• Each URR contains the measurement method (time or volume), and reporting triggers that indicates the
event on which the user plane has to send usage report.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
31
 Cisco Confidential - Limited Release
Overview
Session Delete Response

Session Delete Response

This message sent from the User Plane is in response to a session deletion request from control plane. This
results in the termination of the Sx session at User plane. Usage Report is included as part of SX Delete Session
Response.

Session Report Request and Response Message

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
32
 Cisco Confidential - Limited Release
Overview
Request Message

Request Message
• On encountering a time or volume threshold limit, user plane generates an Sx Session Report Request
message and sends the same to control plane.
• This message contains the Usage report, which indicates the reason for generating the message, specified
by Usage Report Trigger.
• In addition to this, the Usage report contains the time or volume measurement.
• If any other URRs are linked to the URR for which the session report request is being generated, then a
session report request is generated for those linked URRs as well.

Response Message
This message from the Control plane indicates a successful delivery of the Session Report Request message
with a cause code. Currently no specific failure handling is done on receiving a failure cause.

Bit Rate Mapping Support

P-GW converts the bit rate value that it receives from PCRF from bps to kbps. This conversion may lead to
truncation of fractional value to nearest integer (floor) value and lead to loss of information. 3GPP suggested
that if the conversion from bps to kbps leads to a fractional value, then it should be rounded up to the nearest
integer value (ceil) value and sent to the access side.

Note Design changes are done to ensure rounded down (floor) value from bps to kbps is sent on the PFCP interface.

Standards Compliance
The bit rate mapping feature complies with 3GPP TS 29.274 release 12.

Configuring the Bit Rate Mapping Feature

To configure the rounded up (ceil) value for bit rate from bps to kbps in APN-AMBR, GBR, and MBR on
P-GW, perform the following steps:
configure
context context_name
pgw-service service_name
[ no ] egtp bitrates-rounded-down-kbps
end
To configure the rounded down (floor) value for bit rate from bps to kbps in APN-AMBR, GBR, and MBR
on P-GW, perform the following steps:
configure
context context_name
pgw-service service_name
egtp bitrates-rounded-down-kbps
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
33
 Cisco Confidential - Limited Release
Overview
Standards Compliance

New Behavior in CUPS

By default, the rounded up value of bit rate in kbps for APN-AMBR, MBR, and GBR will be sent on the Sx
and GTP interfaces. To enable the rounding down behavior, CLI must be configured.

Standards Compliance
The User Plane in CUPS complies with the following standards:
• 3GPP specification 23.214 release 14.0: Universal Mobile Telecommunications System (UMTS); LTE;
Architecture enhancements for control and user plane separation of EPC nodes
• 3GPP specification 29.244 release 14.0: LTE; Interface between the Control Plane and the User Plane
of EPC Nodes
• 3GPP specification 23.401 release 14.0: 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
34
 Cisco Confidential - Limited Release

CHAPTER 2
Configuring User Plane in CUPS
This section describes the CLI commands available to configure User Plane in CUPS.

Important For information related to following configurations, refer the Ultra Packet Core CUPS Sx Interface
Administration and Reference Guide:
• Configuring Sx Service for CUPS
• Configuring Sx-u Interface for CUPS
• Configuring Sx Demux for CUPS

Important • For Gy, there are no additional configurations at User Plane.

• The following configuration limit applies in CUPS:
• Rulebase - 512
• Ruledef - 2500
• Charging-action - 2048

• Configuring User Plane Service, on page 35

• Associating GTP-U Service with User Plane Service, on page 36
• Associating Sx Service to User Plane Service, on page 37
• Recommended Timers, on page 37

Configuring User Plane Service

Use the following CLI commands to configure the User Plane service.
configure
context context_name
[ no ] user-plane-service service_name
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
35
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
Associating GTP-U Service with User Plane Service

NOTES:
• user-plane-service service_name: Creates the specified User Plane service name to allow configuration
of User Plane service. The service_name is a mandatory parameter to define the User Plane service.
• [ no ] user-plane-service service_name: Removes the User Plane service from the particular context.
• By default, the CLI is disabled.

Starting a User Plane Service

The following minimum and critical parameters must be configured to start the User Plane service:
• One Sx-Service.
• Three GTP-U Services of interface type P-GW ingress, S-GW-ingress, and S-GW-egress.

Important Removal or change of any critical parameters from User Plane service results in
the User Plane service getting stopped.
The services that are associated with User Plane service should be in running
mode. Else, stop in any associated service triggers stopping of User Plane service.

Associating GTP-U Service with User Plane Service

To associate the GTPU service with the User Plane service, execute the following CLI commands:
configure
context context_name
user-plane-service service_name
[ no ] associate gtpu-service gtpu_service_name { pgw-ingress |
sgw-ingress | sgw-egress }
end
NOTES:
• no: Removes association of GTP-U service with the specified interface type from User Plane service.
• associate: Associates User Plane service with GTP-U service.
• gtpu-service gtpu_service_name: Specifies the GTP-U service for the User Plane service.
• pgw-ingress: Configures the interface type as P-GW ingress.
• sgw-ingress: Configures the interface type as S-GW ingress.
• sgw-egress: Configures the interface type as S-GW egress.
• By default, this command is disabled.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
36
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
Associating Sx Service to User Plane Service

Associating Sx Service to User Plane Service

Use the following CLI commands to associate Sx service with User Plane service.
configure
contextcontext_name
user-plane-service service_name
associate sx-service sx_service_name
no associate sx-service
end
NOTES:
• no : Removes association of Sx service from User Plane service.
• Associating Sx service with User Plane service is a mandatory parameter.
• By default, this CLI command is disabled.

Recommended Timers
The following table provides the recommended timer values for CLI commands related to IPSec, Sx, and
SRP.

IPSEC CP UP
ikev2-ikesa max-retransmission 3 3
ikev2-ikesa retransmission-timeout 1000 1000
keepalive interval 4 interval 5
timeout 1 timeout 2
num-retry 4 num-retry 4

Sx CP UP
sx-protocol heartbeat interval 10 10
sx-protocol heartbeat 5 5
retransmission-timeout
sx-protocol heartbeat 4 4
max-retransmissions
sxa max-retransmissions 4 4
sxa retransmission-timeout-ms 5000 5000
sxb max-retransmissions 4 4
sxb retransmission-timeout-ms 5000 5000
sxab max-retransmissions 4 4
sxab retransmission-timeout-ms 5000 5000

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
37
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
Recommended Configurations

IPSEC CP UP
sx-protocol association 60 60
reattempt-timeout
SRP CP UP
hello-interval 3 3
dead-interval 15 15

Recommended Configurations
Following are the recommended configurations and restrictions related to Sx and SRP over IPSec:
• The multihop BFD timer between CP and UP must be seven seconds (for Data UPs).
• The singlehop BFD must be enabled on all the contexts (CP GW/Billing and UP Gn/Gi).
• Inter-chassis multihop BFD must be enabled for CP-CP ICSR and UP-UP ICSR (IMS UP).
• The SRP-IPSec ACL must be configured for TCP protocol instead of IP protocol.
• The Sx-IPSec ACL must be configured for UDP protocol instead of IP protocol.

Example Configurations in CP
Multihop BFD Configuration VPC DI
The following is an example of multihop BFD configuration with seven seconds timer.
bfd-protocol
bfd multihop-peer 192.1.1.1 interval 350 min_rx 350 multiplier 20
bfd multihop-peer 192.1.2.1 interval 350 min_rx 350 multiplier 20
bfd multihop-peer 192.1.0.1 interval 350 min_rx 350 multiplier 20
bfd multihop-peer 192.1.6.1 interval 350 min_rx 350 multiplier 20
bfd multihop-peer 192.1.3.1 interval 350 min_rx 350 multiplier 20
bfd multihop-peer 192.1.4.1 interval 350 min_rx 350 multiplier 20
#exit

Multihop BFD Configuration VPC SI

The following is an example of multihop BFD configuration with three seconds timer.
bfd-protocol
bfd multihop-peer 192.1.1.1 interval 150 min_rx 150 multiplier 20
bfd multihop-peer 192.1.2.1 interval 150 min_rx 150 multiplier 20
bfd multihop-peer 192.1.0.1 interval 150 min_rx 150 multiplier 20
bfd multihop-peer 192.1.6.1 interval 150 min_rx 150 multiplier 20
bfd multihop-peer 192.1.3.1 interval 150 min_rx 150 multiplier 20
bfd multihop-peer 192.1.4.1 interval 150 min_rx 150 multiplier 20
#exit

BGP Configuration
The following is an example of BGP configuration with recommended timers.
router bgp 1111
router-id 192.0.0.1
maximum-paths ebgp 15

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
38
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
Singlehop BFD Configuration

neighbor 192.0.0.101 remote-as 1000

neighbor 192.0.0.101 ebgp-multihop
neighbor 192.0.0.101 update-source 192.0.0.1
neighbor 1111:2222::101 remote-as 1000
neighbor 1111:2222::101 ebgp-multihop
neighbor 1111:2222::101 update-source 1111:2222::1
bgp graceful-restart restart-time 120
bgp graceful-restart stalepath-time 300
timers bgp keepalive-interval 30 holdtime-interval 90 min-peer-holdtime-interval 0
server-sock-open-delay-period 10
address-family ipv4
redistribute connected
#exit
address-family ipv6
neighbor 1111:2222::101 activate
redistribute connected
#exit
#exit

Singlehop BFD Configuration

The following is an example of singlehop BFD configuration with three seconds timer.
interface bgp-sw1-2161-10
ip address 192.0.1.9 255.111.222.0
ipv6 address 1111:222::9/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-11
ip address 192.0.1.10 255.111.222.0
ipv6 address 1111:222::10/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-12
ip address 192.0.1.11 255.111.222.0
ipv6 address 1111:222::11/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-3
ip address 192.0.1.2 255.111.222.0
ipv6 address 1111:222::2/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-4
ip address 192.0.1.3 255.111.222.0
ipv6 address 1111:222::3/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-5
ip address 192.0.1.4 255.111.222.0
ipv6 address 1111:222::4/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-6
ip address 192.0.1.5 255.111.222.0
ipv6 address 1111:222::5/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-7
ip address 192.0.1.6 255.111.222.0
ipv6 address 1111:222::6/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-8

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
39
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
Static Route for Multihop BFD Configuration

ip address 192.0.1.7 255.111.222.0

ipv6 address 1111:222::7/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit
interface bgp-sw1-2161-9
ip address 192.0.1.8 255.111.222.0
ipv6 address 1111:222::8/112 secondary
bfd interval 999 min_rx 999 multiplier 3
#exit

Static Route for Multihop BFD Configuration

The following is an example of static route multihop BFD configuration.
ip route static multihop bfd UP-5 192.111.1.10 192.111.11.10
ip route static multihop bfd UP-6 192.111.1.10 192.111.12.10
ip route static multihop bfd UP-9 192.111.1.10 192.111.10.10
ip route static multihop bfd UP-10 192.111.1.10 192.111.16.10
ip route static multihop bfd UP-7 192.111.1.10 192.111.13.10
ip route static multihop bfd UP-8 192.111.1.10 192.111.14.10

Static Route for Singlehop BFD Configuration

The following is an example of static route singlehop BFD configuration.
ip route static bfd bgp-sw1-2161-3 192.0.1.1
ip route static bfd bgp-sw1-2161-4 192.0.1.1
ip route static bfd bgp-sw1-2161-5 192.0.1.1
ip route static bfd bgp-sw1-2161-6 192.0.1.1
ip route static bfd bgp-sw1-2161-7 192.0.1.1
ip route static bfd bgp-sw1-2161-8 192.0.1.1
ip route static bfd bgp-sw1-2161-9 192.0.1.1
ip route static bfd bgp-sw1-2161-10 192.0.1.1
ip route static bfd bgp-sw1-2161-11 192.0.1.1
ip route static bfd bgp-sw1-2161-12 192.0.1.1

IPSec ACL Configuration

The following is an example IPSec ACL configuration in CP.
ip access-list UP-1
permit udp host 192.0.1.1 host 192.0.1.2
#exit

IPSec Transform Set Configuration

The following is an example of IPSec Transform Set configuration in CP.
ikev2-ikesa transform-set ikesa-UP-1
encryption aes-cbc-256
group 14
hmac sha2-256-128
lifetime 28800
prf sha2-256

ipsec transform-set A-UP-1

encryption aes-cbc-256
hmac sha2-256-128
group 14

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
40
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
IPSec Crypto Map Configuration

IPSec Crypto Map Configuration

The following is an example of IPSec Crypto Map configuration in CP.
crypto map UP-1 ikev2-ipv4
match address UP-1
authentication local pre-shared-key encrypted key secretkey
authentication remote pre-shared-key encrypted key secretkey
ikev2-ikesa max-retransmission 3
ikev2-ikesa retransmission-timeout 1000
ikev2-ikesa transform-set list ikesa-UP-1
ikev2-ikesa rekey
keepalive interval 4 timeout 1 num-retry 4
control-dont-fragment clear-bit
payload foo-sa0 match ipv4
ipsec transform-set list A-UP-1
lifetime 300
rekey keepalive
#exit
peer 192.1.1.1
ikev2-ikesa policy error-notification
#exit

Sx Configuration
The following is an example of Sx configuration in CP.
sx-service SX-1
instance-type controlplane
sxa max-retransmissions 4
sxa retransmission-timeout-ms 5000
sxb max-retransmissions 4
sxb retransmission-timeout-ms 5000
sxab max-retransmissions 4
sxab retransmission-timeout-ms 5000
n4 max-retransmissions 4
n4 retransmission-timeout-ms 5000
sx-protocol heartbeat interval 10
sx-protocol heartbeat retransmission-timeout 5
sx-protocol heartbeat max-retransmissions 4
sx-protocol compression
sx-protocol supported-features load-control
sx-protocol supported-features overload-control
exit
end

Example Router Configurations

Static Routes for Interface
The following is an example configuration of static route for interface.
ip route 192.1.1.1/32 Vlan1111 192.1.1.2
ip route 192.1.1.1/32 Vlan1111 192.1.1.3
ip route 192.1.1.1/32 Vlan1111 192.1.1.4
ip route 192.1.1.1/32 Vlan1111 192.1.1.5
ip route 192.1.1.1/32 Vlan1111 192.1.1.6
ip route 192.1.1.1/32 Vlan1111 192.1.1.7
ip route 192.1.1.1/32 Vlan1111 192.1.1.8
ip route 192.1.1.1/32 Vlan1111 192.1.1.9
ip route 192.1.1.1/32 Vlan1111 192.1.1.10
ip route 192.1.1.1/32 Vlan1111 192.1.1.11

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
41
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
Static Routes for Singlehop BFD

Static Routes for Singlehop BFD

The following is an example configuration of static route for singlehop BFD.
ip route static bfd Vlan1111 192.1.1.2
ip route static bfd Vlan1111 192.1.1.3
ip route static bfd Vlan1111 192.1.1.4
ip route static bfd Vlan1111 192.1.1.5
ip route static bfd Vlan1111 192.1.1.6
ip route static bfd Vlan1111 192.1.1.7
ip route static bfd Vlan1111 192.1.1.8
ip route static bfd Vlan1111 192.1.1.9
ip route static bfd Vlan1111 192.1.1.10
ip route static bfd Vlan1111 192.1.1.11

Interface for Singlehop BFD

The following is an example configuration of interface for singlehop BFD.
interface Vlan1111
no shutdown
bandwidth 10000000
bfd interval 999 min_rx 999 multiplier 3
no bfd echo
ip address 192.1.1.1/24
ipv6 address 1111:222::1/112

BGP Configuration
The following is an example of BGP configuration with recommended timers.
router bgp 1000
router-id 192.1.1.1
timers bgp 30 90
timers bestpath-limit 300
timers prefix-peer-timeout 30
timers prefix-peer-wait 90
graceful-restart
graceful-restart restart-time 120
graceful-restart stalepath-time 300

Example Configurations in UP
IPSec ACL Configuration
The following is an example of IPSec ACL configuration in UP.
ip access-list CP-1
permit udp host 192.0.1.1 host 192.0.1.2
#exit

IPSec Transform Set Configuration

The following is an example of IPSec Transform Set configuration in UP.
ipsec transform-set A-CP-1
encryption aes-cbc-256
hmac sha2-256-128
group 14

ikev2-ikesa transform-set ikesa-CP-1

encryption aes-cbc-256
group 14
hmac sha2-256-128

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
42
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
IPSec Crypto Map Configuration

lifetime 28800
prf sha2-256

IPSec Crypto Map Configuration

The following is an example of IPSec Crypto Map configuration in UP.
crypto map CP-1 ikev2-ipv4
match address CP-1
authentication local pre-shared-key encrypted key secretkey
authentication remote pre-shared-key encrypted key secretkey
ikev2-ikesa max-retransmission 3
ikev2-ikesa retransmission-timeout 1000
ikev2-ikesa transform-set list ikesa-CP-1
ikev2-ikesa rekey
keepalive interval 5 timeout 2 num-retry 4
control-dont-fragment clear-bit
payload foo-sa0 match ipv4
ipsec transform-set list A-CP-1
#exit
peer 192.1.1.2
ikev2-ikesa policy error-notification
#exit

Sx Configuration
The following is an example of Sx configuration in UP.
sx-service SX-1
instance-type userplane
sxa max-retransmissions 4
sxa retransmission-timeout-ms 5000
sxb max-retransmissions 4
sxb retransmission-timeout-ms 5000
sxab max-retransmissions 4
sxab retransmission-timeout-ms 5000
n4 max-retransmissions 4
n4 retransmission-timeout-ms 5000
sx-protocol heartbeat interval 10
sx-protocol heartbeat retransmission-timeout 5
sx-protocol heartbeat max-retransmissions 4
sx-protocol compression
exit

Example SRP Configurations

IPSec ACL Configuration
The following is an example of IPSec ACL configuration for SRP.
ip access-list SRP
permit tcp host 192.1.1.1 host 192.1.1.2
#exit

SRP Configuration
The following is an example of SRP configuration.
configure
context srp
bfd-protocol
bfd multihop-peer 192.1.1.1 interval 999 min_rx 999 multiplier 3
#exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
43
 Cisco Confidential - Limited Release
Configuring User Plane in CUPS
SRP Configuration

configure
context srp
service-redundancy-protocol
chassis-mode primary
hello-interval 3
dead-interval 15
monitor bfd context srp 192.1.1.6 chassis-to-chassis
monitor bgp context gi-pgw 192.1.1.7
monitor bgp context gi-pgw 3333:888::1
monitor bgp context saegw 192.1.1.7
monitor bgp context saegw 3333:888::2
peer-ip-address 192.1.1.6
bind address 192.0.1.6
#exit
ip route static multihop bfd srp 192.0.1.7 192.1.1.7
ip route 192.2.2.2 255.0.0.1 192.2.2.3 SRP-Physical-2102
ip route 192.2.2.4 255.0.0.2 192.2.2.5 SRP-Physical-2102
ip route 192.2.2.6 255.0.0.3 192.2.2.7 SRP-Physical-2102
ip igmp profile default
#exit
#exit
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
44
 Cisco Confidential - Limited Release

CHAPTER 3
Monitoring and Troubleshooting User Plane in
CUPS
This section provides information about the CLI commands available to monitor and/or troubleshoot User
Plane in CUPS.
• Monitoring and Troubleshooting User Plane in CUPS, on page 45
• SNMP Traps, on page 45
• Show Commands, on page 46

Monitoring and Troubleshooting User Plane in CUPS

This section provides information about the CLI commands available to monitor and/or troubleshoot User
Plane in CUPS.

SNMP Traps
The following traps are available after session recovery in the User Plane node:
• starManagerFailure: This trap is generated when there is failure in the Software manager.
• starTaskFailed: This trap is generated when a noncritical task has failed and the appropriate recovery
steps begin.
• starTaskRestart: This trap is generated when a noncritical task has restarted after an earlier failure.
• starSessMgrRecoveryComplete: This trap is generated when Session Manager recovery completes.
This is typically caused by the failure of Session Manager task and successful completion of recovery.
• starManagerRestart: This trap is generated when the identified manager task has been restarted.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
45
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
Show Commands

Show Commands
show configuration
This command displays the following fields:
saegw-service
associate sgw-service
associate pgw-service
associate gtpu-service up-tunnel
associate sx-service

show module p2p user-plane-ipv6-addr

Executing this show command displays the following output:
• Control-Plane Sx-Service name
• Priority
• User-Plane ip
• version
• update/rollback time

show saegw-service all

The output of this command has been enhanced to include the following new field in support of the Sx Service
associated with an SAEGW Service.
sx-service

show saegw-service name

The output of this command is similar to the show saegw-service all CLI command and displays the field
for the specified saegw-service name.

show service all

The output of this command has been modified to include user-plane service and its related parameters.
• Context ID
• Service ID
• Context Name
• Service Name
• State

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
46
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscriber all

• MaxSessions
• Type

show subscriber all

The output of this command has been modified to include user-plane service and its related parameters:
• Access type
• user-plane

• Access Tech
• Call State
• Access CSCF Status
• Link Status
• Network Type
• CALLID
• MSID
• USERNAME
• IP
• TIME-IDLE

show subscribers user-plane-only all

Executing this show command displays the following output:
• Access Type
• Interface Type
• Call State
• CALL ID
• LOCAL SEID
• IP
• PDN-INSTANCE
• TIME-IDLE

showsubscribersuser-plane-onlycalled/seid called/seid flowflow-id flow-id

Executing this show command displays the following output:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
47
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only called/seid called/seid flows full

• Callid
• Interface Type
• IP address
• Flow ID
• Uplink pkts
• Downlink pkts
• Uplink bytes
• Downlink bytes
• UE IP address
• UE Port
• Server IP address
• Server Port
• Protocol

• Total Flows found

• Total subscribers matching specified criteria

show subscribers user-plane-only called/seid called/seid flows full

Executing this show command displays the following output:
• Callid
• Interface Type
• IP address
• Flow ID
• Uplink pkts
• Downlink pkts
• Uplink bytes
• Downlink bytes
• UE IP address
• UE Port
• Server IP address
• Server Port
• Protocol
• Flow ID

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
48
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only called/seid called/seid flows

• Uplink pkts
• Downlink pkts
• UE IP address
• UE Port
• Server IP address
• Server Port
• Protocol

• Total Flows found

• Total subscribers matching specified criteria

show subscribers user-plane-only called/seid called/seid flows

Executing this show command displays the following output:
• Sessmgr Instance
• Application Protocol
• Transport Protocol
• Tethered Flow
• Recovered Flow

• Total Number of Active flows

show subscribers user-plane-only callid call_id pdr all

Executing this show command displays the following output:
• Source Interface
• Type
• Destination Interface
• Type
• vv
• PDR-ID
• Linked FAR-ID
• Linked URR-ID
• Linked QER-ID
• Total subscribers matching specified criteria

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
49
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only callid/seid callid/seid pdr full all

show subscribers user-plane-only callid/seid callid/seid pdr full all

Executing this show command displays the following output:
• Callid
• Interface Type
• IP address

• PDR-ID
• Hits
• Match Bypassed
• Matched Bytes
• Precedence
• Source Interface

• Matched Packets
• SDF Filter(s)
• Filter 1
• Protocol
• Src IP Addr
• Src Port
• Dst IP Addr
• Dst Port

• SPI
• Local F-TEID
• Outer header removal
• Application ID

• Linked FARID
• Destination Interface
• Apply Action
• Outer Header Creation
• Remote TEID
• Remote IP Address
• Remote Port

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
50
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only callid/seid callid/seid pdr id pdr-id

• Linked QERID
• PDR-ID
• Hits
• Match Bypassed
• Matched Bytes
• Precedence
• Source Interface

• SDF Filter(s)
• Filter 1
• Protocol
• Src IP Addr
• Src Port
• Dst IP Addr
• Dst Port
• SPI

• Local F-TEID
• Outer header removal
• Application ID

• Linked FARID
• Destination Interface
• Apply Action
• Outer Header Creation
• Remote TEID
• Remote IP Address
• Remote Port

• Total PDRs found

• Total subscribers matching specified criteria

show subscribers user-plane-only callid/seid callid/seid pdr id pdr-id

Executing this show command displays the following output:
• Callid

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
51
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only callid/seid callid/seid pdr id pdr-id

• Interface Type
• IP address

• PDR-ID
• Hits
• Match Bypassed
• Matched Bytes
• Precedence
• Source Interface

• Matched Packets
• SDF Filter(s)
• Filter 1
• Protocol
• Src IP Addr
• Src Port
• Dst IP Addr
• Dst Port
• SPI

• Local F-TEID
• Outer header removal
• Application ID
• Linked FARID
• Destination Interface
• Apply Action
• Outer Header Creation
• Remote TEID

• Remote IP Address
• Remote Port
• Linked QERID
• Total PDRs found
• Total subscribers matching specified criteria

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
52
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only flows

show subscribers user-plane-only flows

Executing this show command displays the following output:
• Sessmgr Instance
• Application Protocol
• Transport Protocol
• Tethered Flow
• Recovered Flow

• Flow-ID
• Bytes-Up
• Bytes-Down
• Pkts-Up
• Total Number of Active flows
• Total subscribers matching specified criteria

show subscribers user-plane-only full all

Executing this show command displays the following output:
• Local SEID
• Remote SEID
• State
• Connect Time
• Idle time
• Access Type
• Network Type
• user-plane-service-name
• Callid
• Interface Type
• Card/Cpu
• IP allocation type
• IP address
• Source context
• Destination context

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
53
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only full all

• PDN-Instance
• User-plane-Sx-addr
• Control-plane-Sx-addr
• Number of associated PDRs
• Number of associated FARs
• Number of associated QERs
• Number of associated URRs
• input pkts
• output pkts
• input bytes
• output bytes
• input bytes dropped
• output bytes dropped
• input pkts dropped
• output pkts dropped
• pk rate from user(bps)
• pk rate to user(bps)
• ave rate from user(bps)
• ave rate to user(bps)
• sust rate from user(bps)
• sust rate to user(pps)
• pk rate from user(pps)
• pk rate to user(pps)
• ave rate from user(bps)
• ave rate to user(pps)
• sust rate from user(pps)
• sust rate to user(pps)
• ipv4 bad hdr
• ipv4 ttl exceeded
• ipv4 fragments sent
• ipv4 could not fragment
• ipv4 bad length trim

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
54
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show subscribers user-plane-only seid seid pdr all

• ipv4 input mcast drop

• ipv4 input bcast drop
• input pkts dropped (0 mbr)
• output pkts dropped (0 mbr)
• ip source violations
• ipv4 output no-flow drop
• ipv6 bad hdr
• ipv6 bad length trim
• ipv4 input mcast drop
• ipv4 input bcast drop
• input pkts dropped (0 mbr)
• output pkts dropped (0 mbr)
• ip source violations
• ipv4 output no-flow drop
• ipv6 bad hdr
• ipv6 bad length trim
• ipv4 icmp packets dropped
• APN AMBR Input Pkts Drop
• APN AMBR Output Pkts Drop
• APN AMBR Input Bytes Drop
• APN AMBR Output Bytes Drop
• Total subscribers matching specified criteria

show subscribers user-plane-only seid seid pdr all

Executing this show command displays the following output:
• Source Interface
• Type

• Destination Interface
• Type

• vv
• PRD-ID

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
55
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show user-plane-service [ all | name name ]

• Linked FAR-ID
• Linked URR-ID
• Linked QER-ID
• Total subscribers matching specified criteria

show user-plane-service [ all | name name ]

Executing this show command displays the following output:
• Service name
• Service-Id
• Context
• Status
• PGW Ingress GTPU Service
• SGW Ingress GTPU Service
• SGW Egress GTPU Service
• Control Plane Tunnel GTPU Service
• Sx Service

show user-plane-service statistics all

Executing this show command displays the following output:
• VPN Name
• Subscribers Total
• PDNs Total
• Active
• Setup
• Released
• Rejected

• PDNs By PDN-Type
• IPv4 PDNs
• Active
• Setup
• Released

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
56
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show user-plane-service statistics all

• IPv6 PDNs
• Active
• Setup
• Released

• IPv4v6 PDNs
• Active
• Setup
• Released

• PDNs By interface-Type
• Sxa interface-type PDNs
• Active
• Released

• Sxb interface-type PDNs

• Active
• Setup
• Released

• PDNs Rejected By Reason

• No Resource
• Missing or unknown APN
• Addr not alloc
• Addr not present
• No memory available
• System Failure
• PDR install failed

• PDNs Released By Reason

• Network initiated release
• Admin disconnect

• Total Data Statistics

• Uplink
• Total Pkts

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
57
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show user-plane-service statistics all

• Total Bytes
• Total Dropped Pkts
• Total Dropped Bytes

• Downlink
• Total Pkts
• Total Bytes
• Total Dropped Pkts
• Total Dropped Bytes

• Data Statistics Per PDN-Type

• IPv4 PDNs
• Uplink
• Total Pkts
• Total Bytes

• Downlink
• Total Pkts
• Total Bytes

• IPv6 PDN Data Statistics

• Uplink
• Total Pkts
• Total Bytes

• Downlink
• Total Pkts
• Total Bytes

• IPv4v6 PDN Data Statistics

• Uplink
• Total Pkts v4
• Total Bytes v4
• Total Pkts v6
• Total Bytes v6

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
58
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show user-plane-service statistics all

• Downlink
• Total Pkts v4
• Total Bytes v4
• Total Pkts v6
• Total Bytes v6

• Flow Statistics
• Max Flow Reached
• Pkts Dropped - system Limit (L4)
• Ip Flow Statistics
• Total Flows v4
• Uplink
• Total Pkts v4
• Total Bytes v4
• Total Error Pkts v4
• Total Error Bytes v4

• Active Flows v4
• Downlink
• Total Pkts v4
• Total Bytes v4
• Total Error Pkts v4
• Total Error Bytes v4

• Total Flows v6
• Uplink
• Total Pkts v6
• Total Bytes v6
• Total Error Pkts v6
• Total Error Bytes v6

• Active Flows v6
• Downlink
• Total Pkts v6

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
59
 Cisco Confidential - Limited Release
Monitoring and Troubleshooting User Plane in CUPS
show user-plane-service statistics all

• Total Bytes v6
• Total Error Pkts v6
• Total Error Bytes v6

• Udp Flow Statistics

• Total Udp Flows
• Uplink
• Total Udp Pkts
• Total Udp Bytes
• Total Udp Error Pkts
• Total Udp Error Bytes

• Downlink
• Total Udp Pkts
• Total Udp Bytes
• Total Udp Error Pkts
• Total Udp Error Bytes

• TCP Flow Statistics

• Total TCP Flows
• Uplink
• Total TCP Pkts
• Total TCP Bytes
• Total TCP Error Pkts
• Total TCP Error Bytes

• Downlink
• Total TCP Pkts
• Total TCP Bytes
• Total TCP Error Pkts
• Total TCP Error Bytes

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
60
 Cisco Confidential - Limited Release

CHAPTER 4
Smart Licensing
• Revision History, on page 61
• Overview, on page 61
• Configuring Smart Licensing, on page 66
• Monitoring and Troubleshooting Smart Licensing, on page 67

Revision History
Revision Details Release

First introduced. 21.21

Overview
Ultra Packet Core CUPS supports Smart Licensing. Smart Licensing is a cloud-based approach to licensing
that simplifies the purchase, deployment, and management of Cisco software assets. Entitlements are purchased
through your Cisco account via Cisco Commerce Workspace (CCW) and immediately deposited into your
Virtual Account for usage. This eliminates the need to install license files on every device. Products that are
smart-enabled, communicate directly to Cisco to report consumption. A single location is available to customers
to manage Cisco software licenses—the Cisco Smart Software Manager (CSSM). License ownership and
consumption are readily available to help make better purchase decision based on consumption or business
need.
See https://www.cisco.com/c/en/us/buy/smart-accounts/software-licensing.html for more information about
Cisco Smart Licensing.

Comparison Between Legacy Licensing and Smart Licensing

Cisco employs two types of license models - Legacy Licensing and Smart Software Licensing. Legacy
Licensing consists of software activation by installing Product Activation Keys (PAK) on to the Cisco product.
A Product Activation Key is a purchasable item, ordered in the same manner as other Cisco equipment and
used to obtain license files for feature set on Cisco Products. Smart Software Licensing is a cloud-based
licensing of the end-to-end platform leveraging few tools that authorize and deliver license reporting. Smart
Software Licensing functionality incorporated into StarOS completes the product registration, authorization
resulting in reporting services available to the end customer.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
61
 Cisco Confidential - Limited Release
Smart Licensing
Cisco Smart Software Manager

Evaluation Period
A 90-day evaluation period is granted for all licenses in use. During this period, feature licenses can be used
without limitation, and up to one counting license each can be used. The evaluation period ends when the
system registers successfully with the CSSM or Cisco.com. Licensed functionality is blocked when this 90-day
period expires.
CUPS performs license enforcement for on/off feature licenses. Each on/off feature license is tied to service
licenses, which potentially use those on/off features. When an Out of Compliance (OOC) is detected for an
on/off license, new calls for the corresponding services will be dropped, subject to the following conditions:
• Each on/off feature license is given a 90-day grace (evaluation) period. During this period, the system
generates SNMP traps to inform of the unavailability of valid licenses. To resolve the OOC, corrective
action is needed such as purchasing and registering licenses for this feature, or disabling the feature.
• If the feature is still OOC after the 90-day grace period, CUPS enforces the OOC state based on a
predefined policy for each license. If enforcement is required, new calls for the services corresponding
to the on/off licenses are dropped.

The following CLI commands can be used to display details about the enforcement of Smart Licenses in use:
show license enforcement policy
show license enforcement status [ allowed | blocked ] [ feature | service
]

Cisco Smart Software Manager

Cisco Smart Software Manager (CSSM) enables the management of software licenses and Smart Account
from a single portal. The interface allows you to activate your product, manage entitlements, and renew and
upgrade software. A functioning Smart Account is required to complete the registration process. To access
the Cisco Smart Software Manager, see https://software.cisco.com.

Smart Accounts/Virtual Accounts

A Smart Account provides a single location for all Smart-enabled products and entitlements. It helps speed
procurement, deployment, and maintenance of Cisco Software. When creating a Smart Account, you must
have the authority to represent the requesting organization. After submitting, the request goes through a brief
approval process.
A Virtual Account exists as a sub-account withing the Smart Account. Virtual Accounts are a customer-defined
structure based on organizational layout, business function, geography or any defined hierarchy. They are
created and maintained by the Smart Account administrator.
See https://software.cisco.com to learn about, set up, or manage Smart Accounts.

Smart Licensing Mode

The Smart Licensing Mode is categorized as follows:
• Reporting Licenses (Parent Licenses): The Parent Licenses are reported to backend license server
(CSSM) and accounted for usage of licenses. For each Parent Licenses, the entitlement tags are created
and the same is used to identify the type service or feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
62
 Cisco Confidential - Limited Release
Smart Licensing
Request a Cisco Smart Account

• Non-Reporting Licenses (Child Licenses): The Child Licenses are not reported to backend license
server (CSSM) and these licenses are enabled by default with the Parent Licenses. For Child Licenses,
the entitlement tags are not created.

That is to say, Smart License enables all Parent and Child Licenses based on the Product Type that is configured.
However, the reporting is done only for Parent Licenses.
The state of Smart Licensing Agent is persistent across reboot and crashes.

Request a Cisco Smart Account

A Cisco Smart Account is an account where all products enabled for Smart Licensing are deposited. A Cisco
Smart Account allows you to manage and activate your licenses to devices, monitor license use, and track
Cisco license purchases. Through transparent access, you have a real-time view into your Smart Licensing
products. IT administrators can manage licenses and account users within your organization's Smart Account
through the Smart Software Manager.

Step 1 In a browser window, enter the following URL:

https://software.cisco.com

Step 2 Log in using your credentials, and then click Request a Smart Account in the Administration area.
The Smart Account Request window is displayed.

Step 3 Under Create Account, select one of the following options:

• Yes, I have authority to represent my company and want to create the Smart Account – If you select this
option, you agree to authorization to create and manage product and service entitlements, users, and roles on behalf
of your organization.
• No, the person specified below will create the account – If you select this option, you must enter the email address
of the person who will create the Smart Account.

Step 4 Under Account Information:

a) Click Edit beside Account Domain Identifier.
b) In the Edit Account Identifier dialog box, enter the domain, and click OK. By default, the domain is based on the
email address of the person creating the account and must belong to the company that will own this account.
c) Enter the Account Name (typically, the company name).
Step 5 Click Continue.
The Smart Account request will be in pending status until it has been approved by the Account Domain Identifier. After
approval, you will receive an email confirmation with instructions for completing the setup process.

Software Tags and Entitlement Tags

Tags for the following software and entitlements have been created to identify, report, and enforce licenses.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
63
 Cisco Confidential - Limited Release
Smart Licensing
Software Tags and Entitlement Tags

Software Tags
Software tags uniquely identify each licenseable software product or product suite on a device. The following
software tags exist for CUPS.

Product Type / Description Software Tag

CUPS_CP regid.2020-08.com.cisco.CUPS_CP,
1.0_7afd7a3c-38dd-4a04-aecc-26df25029649
4G CUPS - Control Plane

CUPS_UP regid.2020-08.com.cisco.CUPS_UP,
1.0_fd28551c-a541-4902-87af-bba2d6b33cf1
4G CUPS - User Plane

Reporting (Parent) Entitlement Tags for CUPS_CP

The following entitlement tags indentify licenses in use for each product type.

License Display Entitlement Tag License Reporting Tag Name

Name/Description Type Slab

4G CUPS CP 1K regid.2020-08.com.cisco. Counting 1K L_CUPS_CP _

L_CUPS_CP_SAE_1K, SAE_1K
4G CUPS Control
1.0_a84e70b6-d3f9-41c9
Plane 1K Sessions
-8449-4b7bb7426b30

Reporting (Parent) Entitlement Tags for CUPS_UP

The following entitlement tags indentify licenses in use for each product type.

License Display Entitlement Tag License Reporting Tag Name

Name/Description Type Slab

4G CUPS UP 1K regid.2020-08.com.cisco. Counting 1K L_CUPS_UP

L_CUPS_UP_SAE_1K, _SAE_1K
4G CUPS User Plane
1.0_41005ab7-1ad0-46ac
1K Sessions
-905b-c3c5ed402981
4G CUPS UP regid.2020-08.com.cisco. On/Off 1/0 F_CUPS_UP_INS
Instances F_CUPS_UP_INS,
1.0_897c46a0-04b5-4fdb
4G CUPS User Plane
-bedd-9d5fb75bdb76
Instances

Non-reporting (Child) License List

In this release, the following Child Licenses are enabled by default when the Parent Licenses are enabled.

License Description License Type

PGW 1k Sessions Counting
SGW 1k Sessions Counting
GGSN 1k Sessions Counting

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
64
 Cisco Confidential - Limited Release
Smart Licensing
Software Tags and Entitlement Tags

License Description License Type

Per Subscriber Stateful Firewall 1k Sessions Counting
ENAT 1k Sessions Counting
Enhanced Charging Bundle 1 Counting
Enhanced charging bundle 2 On/Off
Dynamic policy interface On/Off
Enhanced LI service On/Off
Lawful intercept On/Off
Session recover On/Off
Radius AAA server group On/Off
IPv6 On/Off
Intelligent Traffic Control On/Off
DIAMETER Closed-Loop Charging Interface On/Off
Per-Subscriber Traffic Policing/Shaping On/Off
Dynamic Radius extensions (CoA and PoD) On/Off
Proxy MIP On/Off
FA On/Off
IPSec On/Off
Inter-Chassis Session Recovery On/Off
ICSR/SR Performance Improvements On/Off
ICSR Enhanced Recovery for Data and Control Plane, 1K Sessions On/Off
MPLS On/Off
TACACS+ On/Off
NAT/PAT With DPI On/Off
Rate Limiting Function (Throttling) On/Off
Overcharging Protection for EPC-GW On/Off
Overcharging Protection Upgrade for EPC-GW On/Off
ADC Trigger Over Gx, 1K Sessions On/Off
Gx Based Virtual APN Selection, 1K Sessions On/Off
EPC-GW Support for Wi-Fi Integration, 1K Sessions On/Off
EPC-GW Non-Standard QCI Support, 1K Sessions On/Off
Local Policy Decision Engine On/Off
Header Enrichment On/Off

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
65
 Cisco Confidential - Limited Release
Smart Licensing
Configuring Smart Licensing

License Description License Type

HTTP Header Encryption On/Off
HTTP Header Enrichment and Encryption On/Off
Broadcast & Multicast Services On/Off
Integrated Content Filtering Provisioned Service On/Off
Application Detection and Control 1k Sessions Counting
5G NSA Feature Set 100K Sess VPCSW Active 1k Sessions Counting
5G NSA Enablement Fee, Network Wide On/Off
Multimedia Priority Service Feature Set,1K Sessions On/Off
EPC Gw VoLTE enhancements On/Off
DNS Snooping On/Off

Configuring Smart Licensing

Before you begin, ensure you have:
• Created a Smart Licensing account on https://software.cisco.com.
• Registered your products on https://software.cisco.com using the Product Instance Registration tokens
created as part of Smart Account/Virtual Account.
• Enabled a communication path between the StarOS system to the CSSM server or Cisco.com.

Enable Smart Licensing

By default, Smart Licensing is disabled in CUPS. To enable Smart Licensing, enter the following Config
mode commands:
configure
license smart product { cups-cp | cups-up }
license smart enable
end
NOTE: Before enabling Smart Licensing, Product Type must be configured to enable default licenses that
are based on product type.
Enter the following command to verify the configuration:
show configuration | grep license

Register the Device with Cisco

Using the Product Instance Registration token ID provided when you registered the products on
https://software.cisco.com, register the system using the following Exec mode command:
license smart register idtoken token

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
66
 Cisco Confidential - Limited Release
Smart Licensing
Monitoring and Troubleshooting Smart Licensing

The system now automatically reports entitlement usage count to the CSSM server and receives a compliance
status. This also removes the system from "Evaluation Mode".
To show the compliance status, enter any of the following Exec mode commands:
show license status
show license summary
show license statistics
The registration for the system is renewed automatically every 180 days. If needed, use the following Exec
mode command to renew the registration information manually:
license smart renew id
The license authorization for the system is renewed automatically every 30 days. If needed, use the following
Exec mode command to renew the license authorization manually:
license smart renew auth
To unregister a device, enter the following Exec mode command:
license smart deregister

Changing Smart Transport URL

Smart Agent uses Smart Transport to communicate to Cisco CSSM server. Smart Transport uses the configured
URL to identify destination URL where CSSM is reachable. This will not initiate any communication with
Cisco. If needed, enter the following Configuration mode commands:
configure
license smart transport smart
license smart url https_link

Handling Out of Compliance

If there are not enough licenses in the virtual account for a given SKU, CSSM sends an Out Of Compliance
(OOC) message to the device. The system stops allowing additional sessions until the OOC state is cleared.
The OOC state is cleared when the device receives an authorized response.

Monitoring and Troubleshooting Smart Licensing

Enter the following Exec mode command to verify the Smart Licensing configuration:
show configuration | grep license
The following Exec mode commands display information about Smart Licensing:
show license { all | enforcement | smart-tags | statistics | status |
summary | tech-support | udi | usage }
NOTES:
• all - Shows a superset of information that includes show status, show usage, show UDI, as well as the
Smart Licensing agent version.
• enforcement { policy | status [ allowed | blocked ] [ feature | service ] } - Shows the enforcement
policy applied or current enforcement status of Smart Licenses. Status information can be filtered to

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
67
 Cisco Confidential - Limited Release
Smart Licensing
Monitoring and Troubleshooting Smart Licensing

show only the licenses which are currently allowed or blocked, or by type (feature license or service
license).
• smart-tags [ feature | service ] - Shows the features and services that are currently supported and the
corresponding Smart Entitlement Tag.
• statistics [ verbose ] - Shows individual feature license status.
• status - Shows overall Smart Licensing status information.
• summary - Shows summary of Smart Licensing status.
• tech-support - Shows information useful for debugging issues with Smart Licensing.
• udi - Shows details for all Unique Device Identifiers (UDI).
• usage - Shows the usage information for all entitlements that are currently in use.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
68
 Cisco Confidential - Limited Release

CHAPTER 5
1:1 User Plane Redundancy for 4G CUPS
• Revision History, on page 69
• Feature Description, on page 69
• How it Works, on page 69
• Configuring 1:1 User Plane Redundancy for 4G CUPS, on page 79
• Monitoring and Troubleshooting, on page 84

Revision History
Revision Details Release

Support is added for session prioritization during recovery. 21.17

Support is added for the following: 21.16.1
• Zero Accounting Loss in User Plane
• Early PDU Recovery

First introduced. 21.15.M0

Feature Description
The 1:1 User Plane Redundancy for 4G CUPS feature supports the detection of a failed User Plane (UP) and
handles seamlessly the functions of the failed UP. Each of the Active UPs has a dedicated Standby UP. The
1:1 UP redundancy architecture is based on the UP to UP Interchassis Session Recovery (ICSR) connection.

How it Works
This section briefly describes how 1:1 User Plane Redundancy for 4G CUPS feature works.
The 4G CUPS deployment leverages the ICSR framework infrastructure for checkpointing and switchover
of the UP node as shown in the following figure. The Active UP communicates to its dedicated Standby UP
via the Service Redundancy Protocol (SRP) link that is provisioned between the UPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
69
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

Figure 1: UP 1:1 Redundancy Using SRP

The Control Plane (CP) node does not have the Standby UP information that is available in the UP group
configuration. Therefore, the CP is not aware of the UP redundancy configuration and the switchover event
among the UPs.
The Active UP communicates to the CP via the Sx interface address configured in the UP. The Standby UP
takes over the same Sx interface address when it transitions to the Active during the switchover event. This
implies that the Sx interface is SRP activated and is in line with the existing configuration method, therefore
UP switchover is transparent to the CP.
Figure 2: UP 1:1 Redundancy Switchover

To make redundancy fully compliant, it addresses the following dependencies on the SRP-based ICSR in the
CUPS environment.
• Synchronization of PFD Configuration
• Sx Association Checkpoint
• Sx Link Monitoring

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
70
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

Besides the dependencies listed, the UP implements data collection and checkpoint procedures specific to the
UP node. For example, checkpointing for IP-pool chunks. The UP integrates these procedures into the existing
ICSR checkpointing framework.
Figure 3: CP-CP ICSR with 1:1 UP Redundancy, before CP Switchover

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
71
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

Figure 4: CP-CP ICSR with 1:1 UP Redundancy, After CP Switchover

Synchronization of PFD Configuration

The CP node pushes the UP configuration via the Packet Flow Description (PFD) messages. The CP sends
the PFD configuration from the Active UP to the Standby UP because the Sx IP address of the UP is
SRP-activated over the Active UP and Standy UP.
The SRP VPN Manager provides the transport between UPs and the Session Controller in the Active UP
anchors the configuration push. The following illustration lists the sequence of events.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
72
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

Figure 5: Synchronizing PFD Configuration

BFD Monitor Between Active UP and Standby UP

The BFD monitors the SRP link between the Active UP and Standby UP for a fast failure detection and
switchover. When the Standby UP detects a BFD failure in this link, it takes over as the Active UP.
The BFD link can be single-hop or multi-hop.

Note The recommendation is that the SRP bind interface must be an Ethernet interface that attaches to the card
service Port. In a loopback address, the recommendation is to ensure that the BFD control packets traverse
only though one service port. If it is the ECMP, ensure that the route convergence time does not exceed the
BFD timeout.

To configure the BFD monitor, between the Active UP and Standby UP, see "Configuring BFD Monitoring
Between Active UP and Standby UP."
Sample Configuration for Multihop BFD Monitoring
Primary UP:
config
context srp
bfd-protocol
bfd multihop-peer 192.168.210.1 interval 50 min_rx 50 multiplier 20
#exit
service-redundancy-protocol
monitor bfd context srp 192.168.210.1 chassis-to-chassis
peer-ip-address 192.168.210.1
bind address 192.168.209.1

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
73
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

#exit
interface srp
ip address 192.168.209.1 255.255.255.0
#exit
ip route static multihop bfd bfd1 192.168.209.1 192.168.210.1
ip route 192.168.210.0 255.255.255.0 192.168.209.10 srp
#exit
end

Backup UP:
config
context srp
bfd-protocol
bfd multihop-peer 192.168.209.1 interval 50 min_rx 50 multiplier 20
#exit
service-redundancy-protocol
monitor bfd context srp 192.168.209.1 chassis-to-chassis
peer-ip-address 192.168.209.1
bind address 192.168.210.1
#exit
interface srp
ip address 192.168.210.1 255.255.255.0
#exit
ip route static multihop bfd bfd1 192.168.210.1 192.168.209.1
ip route 192.168.209.0 255.255.255.0 192.168.210.10 srp
#exit
End

Router between Primary UP and backup UP:

config
context one
interface one
ip address 192.168.209.10 255.255.255.0
#exit
interface two
ip address 192.168.210.10 255.255.255.0
#exit
#exit
end

Sample Configuration for Single Hop BFD Monitoring

Primary UP:
config
context srp
bfd-protocol
#exit
service-redundancy-protocol
monitor bfd context srp 192.168.209.2 chassis-to-chassis
peer-ip-address 192.168.209.2
bind address 192.168.209.1
#exit
interface srp
ip address 192.168.209.1 255.255.255.0
bfd interval 50 min_rx 50 multiplier 10
#exit
ip route static bfd srp 192.168.209.2
#exit
end

Backup UP:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
74
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

config
context srp
bfd-protocol
#exit
service-redundancy-protocol
monitor bfd context srp 192.168.209.1 chassis-to-chassis
peer-ip-address 192.168.209.1
bind address 192.168.209.2
#exit
interface srp
ip address 192.168.209.2 255.255.255.0
bfd interval 50 min_rx 50 multiplier 10
#exit
ip route static bfd srp 192.168.209.1
#exit
end

VPP Monitor
The SRP VPP monitor initiates a switchover to Standby UP when the VPP subsystem fails.

Note The VPP monitor is available only on the VPC-SI instance UP. It is not available in the hybrid CUPS ASR
5500 UP because the card level redundancy handles the VPP failure on the ASR 5500. If VPP causes multiple
card failures, then SRP card monitor must be used.

To configure the VPP monitor, see "Configuring VPP Monitor on Active UP and Standby UP."

Sx Association Checkpoint
Whenever an Active UP initiates a Sx association to the configured CP node, the Standby UP checkpoints
this data. This maintains the association information even after the UP switchover.
The Sx heartbeat messages sends and the Active UP must responds even after back-to-back UP switchovers.

Sx Monitor
It is critical to monitor the Sx interface between the UP and CP. Enabling the Sx heartbeat functionality is
essential because it helps detect a monitor failure.

Note Sx monitoring is available only in the UP.

The Sx interface on the Active UP detects failure and informs the SRP VPN Manager to trigger the UP
switchover event such that the Standby UP takes over.
It is important to ensure that the CP Sx heartbeat timeout is higher than the UP Sx heartbeat timeout plus UP
ICSR switchover time. This is to ensure that the CP does not detect the Sx path failure during a UP switchover
because of the UP Sx monitor failure.
Preventing Control Plane Heartbeat Time Out
There is a minor possibility that the CP heartbeat times out during the UP ICSR switchover. Follow these
steps to mitigate it:
1. Remove the Sx heartbeats from the CP toward the UPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
75
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

2. If the former is not possible, then ensure that the Sx heartbeats from the CP toward the UP have multiple
retry timeout. Also ensure that the number of retries is greater than the UP Sx heartbeat timeout plus UP
ICSR switchover time.
For example:
A = CP heartbeat interval (sx-protocol heartbeat interval)
B = CP heartbeat max retransmissions (sx-protocol heartbeat max-retransmissions)
C = CP heartbeat retransmission timeout (sx-protocol heartbeat retransmission-timeout)
D = UP heartbeat interval (sx-protocol heartbeat interval)
E = UP heartbeat max retransmissions (sx-protocol heartbeat max-retransmissions)
F = UP heartbeat retransmission timeout (sx-protocol heartbeat max-retransmissions)
G = Switchover time (including BGP route convergence time)
Therefore, the formula for successful Sx monitor failure switchover is:
B*C>D+(E*F)+G
Example Values:
CP:
A:
sx-protocol heartbeat interval 60
B:
sx-protocol heartbeat max-retransmissions 10
C:
sx-protocol heartbeat retransmission-timeout 10
UP:
D:
sx-protocol heartbeat interval 30
E:
sx-protocol heartbeat max-retransmissions 3
F:
sx-protocol heartbeat retransmission-timeout 3
BGP:
G: Example route converge time = 30 sec
Therefore, B * C > D + ( E * F ) + G
=> 10 * 10 > 30 + ( 3 * 3 ) + 30
=> 100 > 69
A maximum value of B is 15 and max value of C is 20. Therefore, configure the Sx monitor failure
detection and UP switchover ( D + ( E * F ) + G ) to withstand a maximum delay of 15 * 20 = 300 sec,
that is, 5 min.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
76
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

To minimize the BGP route convergence time (G), run the BGP with BFD fail-over.
To configure the Sx monitor, see "Configuring Sx Monitoring on the Active UP and Standby UP."
The Standby UP itself has no independent connectivity to the CP. The Active UP Sx context is replicated to
the Standby UP such that it is ready to takeover during SRP switchover. This implies that when the Active
UP has switched over to Standby because of Sx monitor failure, the new Standby has no way of knowing if
the UP to CP link is working. To prevent a switchback of the new Standby to Active state again due to Sx
monitor failure in new Active, use the disallow-switchover-on-peer-monitor-fail keyword in the new
monitor sx CLI command.
After a chassis becomes Standby due to Sx monitoring failure, the Sx failure status is not reset even if Sx up
checkpoint is received from the new Active UP. This is to prevent the new Active to cause an unplanned
switchback again due to Sx monitor failure when the previous cause of switchover itself was Sx monitor
failure. This prevents back-to-back ping-pong type of switchovers when CP is down. The Sx monitor failure
status must be manually reset when the operator is convinced that the network connectivity is normal. To
reset, use the new srp reset-sx-fail CLI command (see "Resetting Sx Monitor Failure") in the Standby chassis.

BGP Monitor
Configure BGP peer monitor and peer group monitors for the next-hop routers from UP (both Gi and Gn side)
as shown in the following figure. This is the existing ICSR configuration. BGP may run with BFD assist to
detect fast BGP peer failure.
Figure 6: BGP Peer Groups and Routing

To configure BGP monitoring and flag BPG monitoring failure, see Flagging BGP Monitoring Failure, on
page 80.

UP Session Checkpoints
The Active chassis sends a collection of UP data as checkpoints to the peer Standby chassis in the following
scenarios:
• New call setup
• For every state change in the call
• Periodically for accounting buckets

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
77
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
How it Works

On receiving these checkpoints, the Standby chassis acts on the data and updates the necessary information
either at the call level or node or instance level.

VPN IP Pool Checkpoints

Along with the PFD configuration message, the CP sends the IP pool allocation to each UP. The VPN manager
receives this message in the UP and checkpoints the same information to the Standby UP when the SRP is
configured.
The IP pool information is also sent during the SRP VPNMGR restart and during the SRP link down and up
scenarios.
Validation of the presence of IP pool information in the Standby is vital before switchover. If the IP pool
information is not present, then route advertisement is not possible. Therefore, traffic does not reach the UP.

External Audit and PFD Configuration Audit Interaction

The Active UP performs external audit and PFD configuration audit interaction. The Session Manager gets
a start and complete notification of the PFD configuration audit. The Session Manager does not start the
external audit if the PFD configuration audit is in progress. If the PFD configuration audit start notification
arrives when the external audit is already underway, then the Session Manager raises a flag such that the
external audit restarts when it completes. Restarting the external audit is necessary because it does not achieve
its purpose if it occurs when the PFD audit is already underway.

Zero Accounting Loss for User Plane

Zero accounting loss feature is implemented on User Plane (UP) so that accounting-data/billing loss is reduced
from 18 seconds, which is the default checkpoint time from Active UP to Standby UP, or for the configured
accounting checkpoint time.
This change in UP is to support the Gz, Gy, VoGx, and RADIUS URRs. Only planned switchover is supported
for zero accounting loss/URR data counters loss. This feature does not impact the current ICSR framework
or the way checkpointing is done and recovered.
The Sx usage report is blocked during the “pending active state” till the chassis becomes Active.

Early PDU Recovery for UP Session Recovery

Early PDU Recovery feature overcomes the earlier limitation of Session Recovery feature wherein it did not
prioritize the CRRs that were selected for recovery. All the CRRs were fetched from the AAAMgr and then
the calls were recovered sequentially. The time taken to fetch all the CRRs was a major factor in the perceived
delay during session recovery. When a failure occurred, the delay was sometimes very long if there were a
lot of sessions in a Session Manager. Also, since the calls were recovered in no particular order, the idle
sessions were sometimes recovered before active sessions.

Note The Early PDU Recovery feature can recover a maximum of 5 percent sessions.

Session Prioritization during Recovery

Prior to this release, the Session Recovery function did not prioritize the sessions selected for recovery, and
loops through all the calls in the call recovery list and are recovered sequentially when the session recovery
is triggered.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
78
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
Configuring 1:1 User Plane Redundancy for 4G CUPS

As part of Session Prioritisation during Recovery, a separate skiplist is maintained only for priority calls so
that these records can be sent from AAAMgr immediately without going through the loop, thus leading to
quicker recovery of the priority calls and reducing the data outage time.
There are two types of sessions at User Plane, prioritized sessions and normal sessions. Session is considered
to be prioritized session based on message priority flag received from Control Plane and it is recovered first
followed by normal calls.
These prioritized sessions also take priority in case of early PDU handling. The early PDU of normal calls
will only initiate recovery when all prioritized sessions have been recovered.
In case of critical flush (GR), checkpoints for prioritized sessions are sent first followed by the normal calls.
The data of all the calls (both normal and prioritized) are allowed during switchover.

Note The Control Plane is responsible to set the priority flags for all the calls. The User Plane uses the priority call
details received from the Control Plane for the Session Prioritisation feature.

Configuring 1:1 User Plane Redundancy for 4G CUPS

The following sections provide information about the CLI commands available to enable or disable the feature.

Configuring BFD Monitoring Between Active UP and Standby UP

Use the following commands to configure Bidirectional Forwarding Detection (BFD) monitoring on the
Active UP and Standby UP. This command is configured in the SRP Configuration Mode.
configure
context context_name
service-redundancy-protocol
[ no ] monitor bfd context context_name { ipv4_address | ipv6_address }
{ chassis-to-chassis | chassis-to-router }
exit
NOTES:
• no: Disables BFD monitoring on the Active and Standby UP.
• context context_name : Specifies the context that is used. It refers to the context where the BFD peer is
configured (SRP context).
context_name must be an existing context expressed as an alphanumeric string of 1 through 79 characters.
• ipv4 _address | ipv6_address: Defines the IP address of the BFD neighbor to be monitored, entered using
IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation.
It refers to the IP address of the configured BFD (ICSR) peer.
• chassis-to-chassis | chassis-to-router:
chassis-to-chassis: BFD runs between primary and backup chassis on non-SRP links.
chassis-to-router: BFD runs between chassis and router.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
79
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
Flagging BGP Monitoring Failure

Caution Do not use the chassis-to-router keyword for BFD monitoring on the SRP link
between the Active UP and the Standby UP.

• This command is disabled by default.

Flagging BGP Monitoring Failure

Use the following commands to flag BGP monitor failure on a single BGP peer (User Plane) failure. This
command is configured in the SRP Configuration Mode.

Note • In this release, the exclusive-failover keyword is added to the existing monitor bgp CLI command as
an alternate (new) algorithm to flag BGP monitoring failure.
• For more informnation about the monitor bgp CLI command in the "Service Redundancy Protocol
Configuration Mode Commands" section command of the Command Reference Guide.
• Before adding the exclusive-failover keyword to the existing monitor bgp CLI command, implementing
the monitor bgp command resulted in the following behavior:
• BGP peer group was up if any BGP peer in that group was up.
• Omitting a group configuration for a BGP monitor included that monitor in group 0.
• BGP group 0 monitored in a context from an implicit group. Each context formed a separate BGP
group 0 implicit monitor group.
• BGP monitor was down if any BGP peer group was down.

configure
context context_name
service-redundancy-protocol
[ no ] monitor bgp exclusive-failover
end
NOTES:
• no: Disables flagging of BGP monitor failure on a single BGP peer failure.
• On implementing the new exclusive-failover keyword, the behavior is as follows:
• BGP peer group is Up if any BGP peer in that group is Up.
• Including a BGP peer in group 0 is same as making it non-group (omitting group).
• BGP monitor is down if any BGP peer group or any non-group BGP peer is down.
• Removing a BGP peer being monitored induces a BGP monitor failure.

• This command is disabled by default.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
80
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
Configuring Sx Monitoring on the Active UP and Standby UP

Configuring Sx Monitoring on the Active UP and Standby UP

Use the following commands to configure Sx monitoring on the Active UP and Standby UP. This command
is configured in the SRP Configuration Mode.
configure
context context_name
service-redundancy-protocol
[ no ] monitor sx [ { context context_name | bind-address {ipv4_address
|ipv6_address } | { peer-address {ipv4_address | ipv6_address } } ]
exit
NOTES:
• no: Disables Sx monitoring on the Active and Standby UP.
• contextcontext_name : Specifies the context of the Sx service.
context_name must be an existing context expressed as an alphanumeric string of 1 through 79 characters.
• bind-address { ipv4 _address | ipv6_address}: Defines the service IP address of the Sx service, entered
using IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation.

Note The IP address family of the bind-address and peer-address must be same.

• peer-address { ipv4 _address | ipv6_address}: Defines the IP address of the Sx peer, entered using IPv4
dotted-decimal or IPv6 colon-separated-hexadecimal notation.
• disallow-switchover-on-peer-monitor-fail :
Prevents the switchback of the UP to Active state when the working status of the UP to CP link is
unknown.
• It is possible to implement this CLI command multiple times for monitoring multiple Sx connections.
• The Sx monitor state goes down when any of the monitored Sx connections are down.
• This command is disabled by default.

Configuring SRP over IPSec on the Active UP and Standby UP

IPSec is a suite of protocols that interact with one another to provide secure private communications across
IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security
gateways. IPSec provides confidentiality, data integrity, access control, and data source authentication to IP
datagrams.
The CUPS architecture uses the IPSec protocol to encrypt the packets sent over the Interchassis Session
Recovery (ICSR) connection between the active and standby UPs. This encryption is done by defining an
access-list to match all traffic between Service Redundancy Protocol (SRP) peers and associating it with a
crypto map. This crypto map is used to establish Security Association between IPSec peers residing in UPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
81
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
Configuring SRP over IPSec on the Active UP and Standby UP

Note For more information on IPSec, its features or functionality, and applicable CLI configurations, refer the
StarOS IPSec Reference.

The following CLI command is a sample configuration to configure SRP over IPSec for UPs.
context srp
ip access-list srp-acl
permit tcp host 192.0.2.1 host 192.0.2.2
#exit
ipsec transform-set A-foo
#exit
ikev2-ikesa transform-set ikesa-foo
#exit
crypto map srp-cm ikev2-ipv4
match address srp-acl
authentication local pre-shared-key key local key
authentication remote pre-shared-key key remote key
ikev2-ikesa transform-set list ikesa-foo
payload foo-sa0 match ipv4
ipsec transform-set list A-foo
#exit
peer 192.0.2.3
#exit
service-redundancy-protocol
checkpoint session duration non-ims-session 30
checkpoint session duration ims-session 30
route-modifier threshold 18
delta-route-modifier 2
audit periodicity 60
priority 2
monitor bgp context isp 192.0.2.4
monitor sx context EPC2 bind-address bbbb:abcd::77 peer-address bbbb:abcd::10
peer-ip-address 192.0.2.2
bind address 192.0.2.1
#exit
interface ike-lb loopback
ip address 192.0.2.4 255.255.255.255
crypto-map srp-cm
#exit
interface srp-rtr
ip address 111.111.111.1 255.255.255.0
#exit
interface srp-loopback loopback
ip address 192.0.2.1 255.255.255.255
#exit
ip route 192.0.2.2 255.255.255.255 192.0.2.5 srp-rtr
ip route 192.0.2.3 255.255.255.255 192.0.2.5 srp-rtr
#exit

Note IKEv1 - Transport mode with Authentication Header (AH) protocol is not recommended. Encapsulating
Security Payload (ESP) is recommended because ESP performs both Authentication and Encryption.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
82
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
Configuring VPP Monitor on Active UP and Standby UP

Configuring VPP Monitor on Active UP and Standby UP

Use the following commands to configure Vector Packet Processing (VPP) monitor to trigger UP switchover
on the Active UP if VPP goes down. This command is configured in the SRP Configuration Mode.
configure
context context_name
service-redundancy-protocol
monitor system vpp delay-period 0-300 seconds
exit
no monitor system vpp
NOTES:
• no: Disables VPP monitoring on the Active and Standby UP.
• vpp delay-period0-300 seconds : Specifies the delay period in seconds for a switchover, after a VPP
failure.
If the delay period is a value greater than zero, then the switchover is initiated after the specified delay
period when VPP fails. The last VPP status notification within the delay period is the final trigger for
switchover action. The default value is 0 seconds, which initiates an immediate switchover.
The need for delay is to address the scenario wherein the VPP is temporarily down and the revival is in
process. This implies that a switchover may not be necessary.
• This command is disabled by default.

Preventing User Plane Switchback

Use the following commands to prevent the switchback of the new Standby UP to Active state again due to
Sx monitor failure in the new Active. This command is configured in the SRP Configuration Mode.
configure
context context_name
service-redundancy-protocol
monitor sx disallow-switchover-on-peer-monitor-fail [ timeout
seconds ]
exit
Use either of the following CLIs to allow switchback of the new Standby UP to Active state.

no monitor sx disallow-switchover-on-peer-monitor-fail
Or

monitor sx disallow-switchover-on-peer-monitor-fail timeout 0

NOTES:
• no: Disables prevention of switchover.
• disallow-switchover-on-peer-monitor-fail [ timeout seconds ] : Prevents the switchback of the UP to
Active state when the working status of the UP to CP link is unknown.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
83
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
Resetting Sx Monitor Failure

timeout seconds: Timeout after which the switchback is allowed even if the Sx failure status is not reset
in the Standby peer. The valid values range from 0 to 2073600 (24 days).

Note Assigning 0 seconds as the the timeout allows unplanned switchover.

If timeout keyword is not specified, the Active chassis waits indefinitely for the Sx failure status to be
reset in the Standby peer.
• The default configuration is to allow unplanned switchover due to Sx monitor failure in all conditions.

Note Manual planned switchover is allowed irrespective of whether this CLI is

configured or not.

Resetting Sx Monitor Failure

Use the following command only on the Standby chassis to reset the Service Redundancy Protocol (SRP) Sx
monitor failure information. This command is configured in the Exec Mode.
srp reset-sx-fail

Monitoring and Troubleshooting

This section provides information regarding the CLI command available in support of monitoring and
troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show srp monitor bfd

The output of this CLI command contains the following fields for the 4G CUPS 1:1 UP Redundancy feature:
• Type
• State
• GroupId
• IP Addr
• Port
• Context (VRF Name)
• Last Update

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
84
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
show srp monitor bgp

show srp monitor bgp

The output of this CLI command contains the following fields for the 4G CUPS 1:1 UP Redundancy feature:
• Type
• State
• GroupId
• IP Addr
• Port
• Context (VRF Name)
• Last Update

show srp monitor sx

The output of this CLI command contains the following fields for the 4G CUPS 1:1 UP Redundancy feature:
• Type
• State
• GroupId
• IP Addr
• Port
• Context (VRF Name)
• Last Update

show srp monitor vpp

The output of this CLI command contains the following fields for the 4G CUPS 1:1 UP Redundancy feature:
• Type
• State
• GroupId
• IP Addr
• Port
• Context (VRF Name)
• Last Update

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
85
 Cisco Confidential - Limited Release
1:1 User Plane Redundancy for 4G CUPS
show srp monitor vpp

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
86
 Cisco Confidential - Limited Release

CHAPTER 6
5G NSA for SAEGW in CUPS
• Feature Description, on page 87

Feature Description
Cisco 5G Non Standalone (NSA) solution leverages the existing LTE radio access and core network (EPC)
as an anchor for mobility management and coverage. This solution enables operators using the Cisco EPC
Packet Core to launch 5G services in shorter time and leverage existing infrastructure. Thus, NSA provides
a seamless option to deploy 5G services with very less disruption in the network.
5G is the next generation of 3GPP technology, after 4G/LTE, defined for wireless mobile data communication.
The 5G standards are introduced in 3GPP Release 15 to cater to the needs of 5G networks.
5G Non Standalone (NSA): The existing LTE radio access and core network (EPC) is leveraged to anchor
the 5G NR using the Dual Connectivity feature. This solution enables operators to provide 5G services with
shorter time and lesser cost.

Limitation
• In CUPS architecture, the SGW-C/PGW-C selecting SGW-U/PGW-U based on DCNR is not supported
in this release.
• In this release, APNMBR rate-limit configuration is not supported. The APNMBR policer uses
Auto-readjust internally.
For more information on limitations, refer to the 5G NSA for SAEGW chapter in the 5G Non Standalone
Solution Guide

For additional information about 5G NSA for SAEGW, refer the 5G NSA for SAEGW chapter in the 5G Non
Standalone Solution Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
87
 Cisco Confidential - Limited Release
5G NSA for SAEGW in CUPS
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
88
 Cisco Confidential - Limited Release

CHAPTER 7
Access Control Lists
• Revision History, on page 89
• Feature Description, on page 89
• Configuring Access Control Lists, on page 89
• Monitoring and Troubleshooting, on page 90

Revision History
Revision Details Release

First introduced. 21.9 (5/4/2018)

The Access Control Lists feature is not fully qualified in this release.

Feature Description
The CUPS architecture supports Access Control Lists on the User-Plane. This feature allows the User-Plane
to create and manage IP access privileges for a subscriber.

Configuring Access Control Lists

An existing configuration, which is part of the non-CUPS architecture is implemented for this feature. The
ip access-list command – part of the Context Configuration mode is used to implement an access control list.

Note For CUPS, the same configuration is implemented on a User Plane’s APN Configuration mode.

Use the following configuration to create and manage IP-based, user access privileges:
configure
context context_name
ip access-list acl_name
{ deny | permit } [ log ] source_address source_wildcard

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
89
 Cisco Confidential - Limited Release
Access Control Lists
Monitoring and Troubleshooting

no { deny | permit } [ log ] source_address source_wildcard

end
NOTES:
• no: Removes the rule which exactly matches the options specified.
• deny | permit: Specifies the rule is either block (deny) or an allow (permit) filter.
• deny: Indicates the rule, when matched, drops the corresponding packets.
• permit: Indicates the rule, when matched, allows the corresponding packets.

• log: Indicates all packets which match the filter are to be logged. By default, packets are not logged.
• source_address: The IP address(es) from which the packet originated. IP addresses must be entered
in IPv4 dotted-decimal format.
This option is used to filter all packets from a specific IP address or a group of IP addresses.
When specifying a group of addresses, the initial address is configured using this option. The range
can then be configured using the source_wildcard parameter.
• source_wildcard: This option is used in conjunction with the source_address option to specify a
group of addresses for which packets are to be filtered.
The mask must be entered as a complement:
• Zero-bits in this parameter mean that the corresponding bits configured for the source_address
parameter must be identical.
• One-bits in this parameter mean that the corresponding bits configured for the source_address
parameter must be ignored.

Note The mask must contain a contiguous set of one-bits from the least significant bit
(LSB). Therefore, allowed masks are 0, 1, 3, 7, 15, 31, 63, 127, and 255. For
example, acceptable wildcards are 0.0.0.3, 0.0.0.255, and 0.0.15.255. A wildcard
of 0.0.7.15 is not acceptable since the one-bits are not contiguous.

Monitoring and Troubleshooting

This section provides information regarding monitoring and troubleshooting the Access Control Lists feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show sub user-plane-only full all

On executing the above command, the following fields are displayed for this feature:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
90
 Cisco Confidential - Limited Release
Access Control Lists
show sub user-plane-only full all

• active input acl

• active output acl
• ipv4 input acl drop
• ipv4 output acl drop

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
91
 Cisco Confidential - Limited Release
Access Control Lists
show sub user-plane-only full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
92
 Cisco Confidential - Limited Release

CHAPTER 8
ADC Over Gx
• Feature Description, on page 93
• How It Works, on page 94
• Configuring ADC over Gx, on page 95
• Monitoring and Troubleshooting, on page 96

Feature Description
In compliance with 3GPP TS 29.244 V15.0.0, ADC over Gx feature supports the following functionalities in
CUPS environment:
• Application START/STOP event reporting at the instance level, over the Sx Interface, as part of the
session usage report request.
• Application START/STOP is sent for Group of Ruledef when a flow matches the Group of Ruledef.
• Supports AND logic for rulelines while matching ADC ruledefs.
• Supports new Information Elements (IEs) for Packet Forwarding Control Protocol (PFCP) messages that
are used for ADC application detection notifications.

Important In this release, the ADC Over Gx feature is applicable for ADC L3/L4 rules.

Important For supplemental information about ADC Over Gx feature in non-CUPS environment, refer to:
• ADC Support over Gx section in the Application Detection and Control Overview chapter of the ADC
Administration Guide.
• Support ADC Rules over Gx Interface section in the Gx Interface Support chapter of the P-GW
Administration Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
93
 Cisco Confidential - Limited Release
ADC Over Gx
How It Works

How It Works
For ADC over Gx feature in CUPS environment, support has been added for the following:
• The Application ID/TDF Application Identifier is part of the PDI of PDR, either in Sx Establishment
Request or Sx Session Modify Request.
• Handling of the ADC rule match on U-Plane.
• To generate a session usage report request when the Application START/STOP event occurs on U-Plane.
• New IEs as part of the Usage report request:
• Application ID
• Application Instance ID
• Flow Information

• Monitor Protocol to decode the new IEs.

• To handle the usage report request that is received, and trigger the CCR-U to PCRF on C-Plane.

The functionality of ADC Over Gx feature consists of the following components, and each are described in
this section.

ADC Rule Match

The ADC rule match is invoked after the traditional rule match. After the L3/L4 filters are being matched,
the rule match engine checks for any ADC rules being configured on the bearer. If ADC rules are present,
then the ADC rule match occurs.
If the bearer has ADC rule which does not have the L3/L4 filters, and it’s a non-GBR bearer, then the ADC
rule match is done across all the non-GBR bearers. The charging is done against the charging and action policy
of the rule match.
In case of ADC dynamic rules, if the L3/L4 filter matches but the ADC rule match fails, then the rule is
considered as not matched.

Session Usage Report Request Generation

Once the ADC rule matches on the U-Plane and an application has been detected, the U-Plane triggers the
Application START notification over the Sx interface as a session usage report:
• With the measurement method set to Event,
• Usage Report Trigger set to “Start of Traffic”, and
• The Application Detection Info, such as Application ID, Application Instance ID, and Application Flow
Information along with the direction.

When the application teardown gracefully, or the application gets timed out, or the rule match changes, the
application STOP is triggered from U-Plane to C-Plane as a session usage report:
• With the measurement method set to “Event”,

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
94
 Cisco Confidential - Limited Release
ADC Over Gx
Limitations

• Usage Report Trigger set to “Stop of Traffic”,

• Application ID, and
• Application Instance ID.

The application STOP is not triggered when:

• “mute” is enabled.
• The call is going down.
• The rule/PDR is being deleted.
• The bearer/tunnel deletion occurs.

Handling Session Usage Report on C-Plane

On receiving the session usage report on C-Plane, it detects the event and CCR-U is triggered toward PCRF,
along with the required attributes to be sent.

Limitations
Following are the known limitations of the ADC Over Gx feature:
• When the TDF Application Identifier on the U-Plane and the “policy-control bypass TDF-ID-validation
CLI command are not present, the calls are dropped. And, the proper disconnect reason is not being
shown.
• The configuration change for predefined ADC rules, such as "mute" to "unmute" and "unmute" to "mute"
scenarios are not supported in this release.
• Mid-session update and/or modification of ADC rules—whether change in configuration or PDN update
over RAR, is not supported.
• ADC is supported for L3/L4 rules on default bearer.

Licensing
ADC over Gx feature requires Application Detection Control License. Contact your Cisco account representative
for detailed information on specific licensing requirements.

Configuring ADC over Gx

The CLI commands available for ADC Over Gx in non-CUPS environment can be used in CUPS environment.
Following are the sample configurations to:
• Enable the feature under Policy Control Configuration mode:
diameter encode-supported-features adc-rules

• Configure ADC predefined rule under ACS Rulebase Configuration mode:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
95
 Cisco Confidential - Limited Release
ADC Over Gx
Monitoring and Troubleshooting

action priority 55 dynamic-only adc ruledef qci5 charging-action charge-action-qci5

action priority 56 dynamic-only adc mute group-of-ruledefs qci5_gor charging-action
charge-action-qci5

Important Application START/STOP will not be sent to PCRF if the Application START/STOP event trigger is not
registered while enabling the ADC Over Gx feature.

Important For additional information about the CLI commands, refer the Command Line Interface Reference.

Monitoring and Troubleshooting

This section describes the CLI commands available to monitor and/or troubleshoot the feature.

Monitor Protocol
When using the monitor protocol command, enable option 49 to see ADC related parameters in Sx messages.

Show Command(s) and/or Outputs

On C-Plane

show active-charging subscribers callid <callid> urr-info

The output of this show command has been modified to display the ADC URRs along with Volume and
Duration related URRs.

On U-Plane

show subscribers user-plane-only full all

The output of this show command has been modified to display the “Number of associated ADC PDRs”.

show subscribers user-plane-only callid <callid> pdr full all

The output of this show command has been modified to display the following new fields:
• TDF App Id
• TDF Notifications
• Total ADC PDRs found

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
96
 Cisco Confidential - Limited Release
ADC Over Gx
On U-Plane

show subscribers user-plane-only callid <callid> urr full all

The output of this show command has been modified to display the ADC URRs along with Volume and
Duration related URRs.

show user-plane-service rulebase name <rulebase_name>

The output of this show command has been enhanced in support of this feature. Two new Type characters
are introduced to identify ADC rules and ADC rules with “mute”:
• RDA – Where A is for ADC rule
• GDAM – Where AM is for ADC rule with “mute”

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
97
 Cisco Confidential - Limited Release
ADC Over Gx
On U-Plane

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
98
 Cisco Confidential - Limited Release

CHAPTER 9
Addition of IP Pool in IP Group
• Revision History, on page 99
• Feature Description, on page 99
• How it Works, on page 100
• Monitoring and Troubleshooting, on page 100

Revision History
Revision Details Release

First introduced. 21.16

Feature Description
In the existing CUPS platform, when a new IP pool is added, only the User Planes (UPs) that register after
the creation of the new pool can use these pools. If any existing UP requires to use the new pool, a UP reload
or UP reassocation is performed.
The Addition of IP Pool in IP Group feature ensures that when a new IP pool is added, each existing UP is
evaluated based on whether its APN configuration makes it eligible to get chunks from this new pool. If the
UP is eligible, then chunks are allocated to the UP and it is used for future call allocation.
The eligibility of the UP is determined in the following scenarios:
• APN has a pool-group configured. A new pool is added under this pool-group.
• APN has no pool-name or pool-group configured . A new public pool is added.

Note Any changes implemented on the APN do not take affect until the UP is reassociated or reloaded.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
99
 Cisco Confidential - Limited Release
Addition of IP Pool in IP Group
How it Works

How it Works
This section briefly describes how the Addition of IP Pool in IP Group feature works.

Adding New Pools in a CP-CP ICSR Environment

1. Add the new pool in the Standby Control Plane (CP).
2. Add the new pool in the Active CP.
Chunks are allocated to the eligible UPs and the same are checkpointed to the Standby CP.
3. Verify whether show { ip | ipv6 } pool-chunks pool-name <name> command in both the CPs are
synchronized.

Delete Pools in CP-CP ICSR Environment

1. Delete the pool in the Active CP.
2. Ensure that all the IPs are free from the deleted pool in the Standby CP, using the show { ip | ipv6 } pools
command.
3. Delete the pool in the Standby CP.

Monitoring and Troubleshooting

This section provides information regarding the CLI command available in support of monitoring and
troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show ip user-plane verbose

The output of this CLI command displays the following fields in support of the Addition of IP Pool in IP
Group feature in CUPS mode:
• Dynamic pool count
• apn-without-pool-name-v4
• apn-without-pool-name-v6
• Pool-groups
• Pool-Group-Names

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
100
 Cisco Confidential - Limited Release

CHAPTER 10
APN ACL Support
• Revision History, on page 101
• Feature Description, on page 101
• Troubleshooting, on page 102

Revision History
Revision Details Release

First introduced. 21.19

Feature Description
Currently in CUPS (pre 21.19.x release), the APN level ACL definitions are configured on UP.
With this feature, ACLs configured on CP are pushed to UP. This feature saves the cost and effort of configuring
separate ACL definitions on all UP nodes.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
101
 Cisco Confidential - Limited Release
APN ACL Support
Troubleshooting

Note • Verify the APN ACLs in CP configuration before proceeding with the upgrade to the release.
• The configuration must have the same context names in both CP and UP. CP can have more contexts
than UP. If the context names do not match, the respective ACLs are dropped at UP.
• It is recommended to not define APN ACLs in both CP and UP. However, if there is a requirement, the
ACL names in both UP and CP must be different from each other to avoid any conflicts.
• To ensure backward compatibility, ACLs locally created in UP configuration gets preference.
• If an APN belongs to a specific user-plane-group, ACLs for the same APN are pushed to only those UPs,
which are part of the same user-plane-group.
• A maximum of 64 contexts is allowed and a maximum of 16 ACLs per context.
• Multiple APNs can share an ACL in the same context.
• Changes to an ACL are applicable only for new sessions, but not for ongoing sessions.
• If a deny any rule is configured in IPv6 ACLs, the Router advertisement (RA) and Router Solicitation
(RS) messages must be explicitly allowed in ACL.

Troubleshooting
This section describes how to troubleshoot this feature.

Note This feature is enabled by default.

Show commands
This section describes the show commands for this feature.

show user-plane-service ip-access-list name access list name

This command is used to display ACL rules on user plane.

show user-plane-service pdn-instance name apn name

This command is used to display the access group for an apn on user plane.

show srp statistics

This command is used to display the sent, received, and discarded packet count for APN ACLs over SRP.

show demux-mgr statistics sxdemux all

This show command is used to display the number of PFD ACL_INFO packets sent from CP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
102
 Cisco Confidential - Limited Release

CHAPTER 11
APN AMBR Traffic Policing
• Revision History, on page 103
• Feature Description, on page 103
• Configuring the APN AMBR Traffic Policing Feature, on page 103
• Monitoring and Troubleshooting, on page 104

Revision History
Table 1: Revision History

Revision Details Release

First introduced. 21.19

Feature Description
The APN-AMBR is a subscription parameter stored per APN in the HSS. S-GW provides APN-AMBR during
default bearer establishment procedure. APN-AMBR limits the aggregate bit rate that can be expected to be
provided across all non-GBR bearers and across all PDN connections of the same APN. Each of those non-GBR
bearers could potentially utilize the entire APN-AMBR, for example, when the other non-GBR bearers don’t
carry any traffic. The P-GW enforces the APN-AMBR in downlink and uplink direction.
As part of this CLI-controlled feature, the CLI parameters must be configured on Control Plane and propagated
to User Plane through Sx interface.

Limitations
The following is the known limitation of APN-AMBR Traffic Policing feature:
• Configuring token-replenishment-interval and violate-action shape CLIs aren’t supported.

Configuring the APN AMBR Traffic Policing Feature

This section describes how to configure the APN-AMBR Traffic Policing feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
103
 Cisco Confidential - Limited Release
APN AMBR Traffic Policing
Monitoring and Troubleshooting

configure
context context_name
apn apn_name
apn-ambr rate-limit direction { downlink | uplink } [ burst-size
{ auto-readjust duration { milliseconds msecs | seconds } | violate-action
{ drop | lower-ip-precedence | transmit }
end
NOTES:
• rate-limit direction { downlink | uplink }: Specifies that the rate limit is to be applied to either the
downlink (network to subscriber) traffic or the uplink (subscriber to network) traffic.
• burst-size { auto-readjust duration milliseconds msecs | seconds }: This parameter is used by policing
algorithms to permit short bursts of traffic not to exceed the allowed data rates. It’s the maximum size
of the token bucket.
• auto-readjust durationseconds: The duration (in seconds) used in this burst size calculation: burst
size = peak data rate/8 * auto-readjust duration.
• Seconds must be an integer value from 1-30. Default is 1 second.

• milliseconds: msecs must be an integer value from 100-900, in increments of 100 milliseconds. For
example, 100, 200, or 300, and so on.

• violate-action { drop | lower-ip-precedence | transmit }: The action that the P-GW takes when the data
rate of the bearer context exceeds the AMBR.
• drop: Drops violating packets.
• lower-ip-precedence: Sets the DSCP value to zero ("best effort") for violating packets.
• transmit: Transmits violating packets. This is the default behavior of the feature.

• Prior to this feature, the default behavior was to drop the violating packets.

Monitoring and Troubleshooting

This section provides information about the commands available to monitor and/or troubleshoot the
APN-AMBR Traffic Policing feature.

Show Commands and or Outputs

This section provides information about the show commands available for monitoring and/or troubleshooting
the APN-AMBR Traffic Policing feature.
• show user-plane-service pdn-instance name <apn_name>: The following APN-AMBR information
is available on User Plane after APN-AMBR CLI is configured on Control Plane and PFD Push to User
Plane is completed:
• APN-AMBR
• Downlink Apn Ambr: Indicates if the rate limit is enabled or disabled for downlink traffic.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
104
 Cisco Confidential - Limited Release
APN AMBR Traffic Policing
Show Commands and or Outputs

• Burst Size: Indicates the burst size of the downlink traffic.

• Auto Readjust: Indicates if the auto-readjust is enabled or disabled for downlink burst
size.
• Auto Readjust Duration: Indicates the duration used in downlink burst size calculation.
• Burst Size(bytes): Indicates the burst size in bytes.
• Violate Action: Indicates the action that the P-GW takes when the data rate of the bearer
context exceeds the AMBR for downlink traffic.

• Uplink Apn Ambr: Indicates if the rate limit is enabled or disabled for uplink traffic.
• Burst Size: Indicates the burst size of the uplink traffic.
• Auto Readjust: Indicates if the auto-readjust is enabled or disabled for uplink burst size.
• Auto Readjust Duration: Indicates the duration used in uplink burst size calculation.
• Burst Size(bytes): Indicates the burst size in bytes.
• Violate Action: Indicates the action that the P-GW takes when the data rate of the bearer
context exceeds the AMBR for uplink traffic.

• Token Replenishment Interval: Indicates the token replenishment interval duration.

• show sub user-plane-only full all:

Use this show command in User Plane to see the count of packets that are dropped, and IP precedence
lowered due to APN-AMBR policer. The following fields are introduced in support of this feature:
• APN AMBR Uplink Pkts Drop: Indicates the number of APN-AMBR packets that are dropped for
uplink traffic.
• APN AMBR Uplink Bytes Drop: Indicates the number of APN-AMBR bytes that are dropped for
uplink traffic.
• APN AMBR Uplink Pkts IP pref lowered: Indicates the number of APN-AMBR uplink packets for
which IP precedence is lowered.
• APN AMBR Uplink Bytes IP pref lowered: Indicates the number of APN-AMBR uplink bytes for
which IP precedence is lowered.
• APN AMBR Downlink Pkts Drop: Indicates the number of APN-AMBR packets that are dropped
for downlink traffic.
• APN AMBR Downlink Bytes Drop: Indicates the number of APN-AMBR bytes that are dropped
for downlink traffic.
• APN AMBR Downlink Pkts IP pref lowered: Indicates the number of APN-AMBR downlink packets
for which IP precedence is lowered.
• APN AMBR Downlink Bytes IP pref lowered: Indicates the number of APN-AMBR downlink
bytes for which IP precedence is lowered.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
105
 Cisco Confidential - Limited Release
APN AMBR Traffic Policing
Show Commands and or Outputs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
106
 Cisco Confidential - Limited Release

CHAPTER 12
APN Data Tunnel MTU Size Configuration
• Revision History, on page 107
• Feature Description, on page 107
• Configuring MTU, on page 108

Revision History
Revision Details Release

First introduced. 21.13 (2/26/2019)

Feature Description
The enhanced packet core (EPC) defines many different interfaces that require encapsulation of IPv4 and
IPv6 data packets. Because the EPC adds encapsulating headers, additional care must be taken when fragmenting
IPv4 and IPv6 packets.
Appropriate configuration should not result in fragmentation at any node in EPC. This feature fragments the
IPv6 and IPv4 packets based on their MTU.
In RFC-4861 there is a provision to send the Maximum Transmission Unit (MTU) in Router Advertisement
(RA) messages. P-GW supports the sending of the IPv6 MTU option in RAs for IPv6 and IPv4v6 PDN types
towards the UE. The (Internet) can now send downlink data packet and based on the configured MTU, data
fragmentation is performed at the source, if required. This feature also reduces the number of ICMPv6 Packet
Too Big Error messages in the customer's network.
The MTU size is configurable through the Command Line Interface (CLI) on P-GW.

Limitation
• For P-GW/SAEGW IPv6 session, when packet exceeds the APN MTU value the CLI policy ipv6 tunnel
mtu exceed notify-sender is not supported as ICMP is not available in VPP.
• For GGSN/P-GW/SAEGW IPv4 session, when packet (with df bit) exceeds the APN MTU value the
CLI access-link ip-fragmentation df-fragment-and-icmp-notify is not supported as ICMP is not
available in VPP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
107
 Cisco Confidential - Limited Release
APN Data Tunnel MTU Size Configuration
Configuring MTU

• For GGSN/P-GW/SAEGW IPv4 session, when packet (with df bit) exceeds the APN MTU value the
CLI access-link ip-fragmentation normal is not supported as ICMP is not available in VPP.

Configuring MTU
The following CLI commands configures the Maximum Transmission Unit (MTU) for data sent on the IPv4
and IPv6 tunnel between the P-GW and the mobile node:
configure
context context_name
apn apn_name
ppp mtu bytes
data-tunnel mtu bytes
policy ipv6 tunnel mtu exceed { fragment inner | notify-sender |
fragment }
access-link ip-fragmentation { df-ignore | normal |
df-fragment-and-icmp-notify }
end
NOTES:
• bytes: Specifies the MTU for the IPv6 tunnel between the P-GW and the mobile node. bytes must be an
integer between 1280 and 2000. Default: 1500.
• ppp: Specifies data sent on the IPv4 tunnel between P-GW and mobile node.
• data-tunel mtu: Specifies data sent on the IPv6 tunnel between P-GW and mobile node.
• fragment inner: Performs one time fragment at GTP tunnel initiator.
• notify-sender: System will drop the incoming packet and send "ICMPv6 Packet Too Big" to the original
sender.

Note This is also the default CLI configuration, hence this should be the default behavior
when nothing is explicitly configured.

• fragment: Performs fragmentation or reassembly at intermediate GTP hops.

• df-ignore: Ignores the DF (Don't Fragment) bit setting; fragments and forwards the packet over the
access link.

Note This is also the default CLI configuration, hence this should be the default behavior
when nothing is explicitly configured.

• df-fragment-and-icmp-notify: Partially ignores the DF bit; fragments and forwards the packet, but also
returns an ICMP error message to the source of the packet. The number of ICMP errors sent like this is
rate-limited to one ICMP error packet per second per session.
• normal: Drops the packet and sends an ICMP unreachable message to the source of packet.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
108
 Cisco Confidential - Limited Release

CHAPTER 13
App-based Tethering Detection in User Plane
• Revision History, on page 109
• Feature Description, on page 109
• Configuring App-based Tethering Detection, on page 110
• Monitoring and Troubleshooting the App-based Tethering Detection, on page 111

Revision History
Revision Details Release

First introduced. 21.14.M0 (5/31/2019)

Feature Description

Important The App-based Tethering Detection is an existing feature that is supported in non-CUPS architecture. With
this release, the feature is supported in the CUPS architecture.

The App-based Tethering Detection solution is built around the existing ADC plugins for App identifications.
Tethering-specific patterns are added on top of recognized App plugins. These plugins successively return if
the App flow is tethered or not. The App based Tethering Detection interworks with other existing supported
tethering technique.
Similar to non-CUPS architecture, the tethering detection is currently supported only for Netflix and Youtube.
This feature on CUPS is in parity with non-CUPS tethering pattern detection technique.
For more information about App-based Tethering Detection, refer the App-based Tethering Detection chapter
in the ADC Administration Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
109
 Cisco Confidential - Limited Release
App-based Tethering Detection in User Plane
Limitation

Limitation
This feature on CUPS is in parity with non-CUPS tethering pattern detection technique. And so, if there are
any new TLS patterns used by tethered devices in the network, then those are not identified for tethering
detection.

Configuring App-based Tethering Detection

This section describes how to enable support for App-based Tethering Detection.

Enabling App-based Tethering Detection at Rulebase Level

Important The tethering configuration must be done on Control Plane and then, it must be pushed to User Plane.

Use the following commands to enable App-based Tethering Detection for ADC traffic under ACS Rulebase
Configuration Mode:
configure
active-charging service service_name
rulebase rulebase_name
tethering-detection application
exit
exit
exit
NOTES:
• The default tethering-detection command configures its default setting.
Default: By default, the Tethering Detection feature is disabled.

Important The OS and UA-based tethering detection are currently not supported in CUPS.

• If previously configured, use the no tethering-detection command to remove the tethering detection
configuration from the rulebase.

Verifying App-based Tethering Detection at Ruledef Level

Use the following commands to verify tethered or non-tethered traffic through ruledef matching:
configure
active-charging service service_name
ruledef ruledef_name
tethering-detection application { flow-tethered | flow-not-tethered
}
exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
110
 Cisco Confidential - Limited Release
App-based Tethering Detection in User Plane
Monitoring and Troubleshooting the App-based Tethering Detection

exit
exit
NOTES:
• If previously configured, use the no tethering-detection command to remove the tethering detection
configuration from the ruledef.

Monitoring and Troubleshooting the App-based Tethering

Detection
This section provides information regarding commands available to monitor and troubleshoot the App-based
Tethering Detection.

Show Commands and Outputs

This section provides information regarding show commands and their outputs in support of this feature.

show user-plane-service statistic tethering-detection

The output of this CLI command has been enhanced to include the following fields in support of this feature.
• Tethering Detection Statistics (Application):
• Total flows scanned
• Tethered flows detected
• Tethered uplink packets
• Tethered downlink packets

show user-plane-service statistic rulebase name <rulebase_name>

The output of this CLI command has been enhanced to include the following fields in support of this feature.
• Tethering Detection (Application):
• Total flows scanned
• Tethered flows detected
• Tethered uplink packets
• Tethered downlink packets

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
111
 Cisco Confidential - Limited Release
App-based Tethering Detection in User Plane
Show Commands and Outputs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
112
 Cisco Confidential - Limited Release

CHAPTER 14
APN and APN Profile-Based User Plane
Selection for CUPS
• Revision History, on page 113
• Feature Description, on page 113
• How It Works, on page 113
• Configuring APN-Based UP Grouping, on page 116
• Monitoring and Troubleshooting APN-Based UP Grouping, on page 118

Revision History
Revision History

Revision Details Release

First introduced. 21.12 (12/21/2018)

Feature Description
Currently, in CUPS architecture, User Plane is selected by SAEGW-C using an algorithm that selects least
connected User-Plane. Also, there is a flat list of User Plane among which User Plane is selected.
With this feature, Operator can select User Plane from specific UP group associated with an APN/APN Profile.

How It Works
Cisco CUPS solution supports Static UP selection. This is based on static selection of active SAEGW-U
available. UP Group concept is used for static UP selection. UP group is a group of UP SAEGW-Us. Each
APN is then associated with one UP group. APN is served by the UP groups associated with it. UPs are
selected using an algorithm that selects least connected User-Plane available in that particular group.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
113
 Cisco Confidential - Limited Release
APN and APN Profile-Based User Plane Selection for CUPS
How It Works

UP Group
On SAEGW-C, for Static UP selection, UP group concept is used. An UP group is a list of UPs (SAEGW-Us).
An UP can be part of only one UP group. In a UP Group, all the UPs need to be of same capacity and capability.
Different type of UPs should be part of different UP group. The following two types of UP groups are supported:
• Specific UP group—It is a set of explicitly configured UPs. Specific group gives the flexibility to group
certain specific types of UPs together. This helps in reserving specific set of UPs for a specific purpose.
There can be multiple Specific groups that can be configured.
• Default UP group—This is a default group which groups all the UPs that are registered and are not
explicitly configured as part of any Specific UP group. Default group has advantage of registering UPs
in zero touch manner without having the need to explicitly configure a UP on the CP. This kind of group
is more suited for collocated CUPS case where all the UPs are of same capacity and capability and are
in the same data center. Default group optimizes the UP config on the CP.

An APN can be associated with UP group. If no group is associated with an APN, then default UP group is
used to serve that APN. Similarly, for selecting UP for Pure-S calls, UP group can be associated to an APN
profile. If there is no APN Profile/Operator-Policy defined or no group is associated with APN Profile, then
SAEGW-C uses “default” UP group for selection.
Operator can reserve certain UPs for certain application. For example, IMS vs. Internet vs. IOT can have
different UP groups.
With this feature:
• SAEGW-C always has one User Plane group with the name “default”.
• SAEGW-C supports maximum of 100 User Planes.
• User planes can be organized in different group.
• Currently, 100 user-plane-groups can be configured, and single group can have maximum of 100 User
Planes.
• One User Plane can be part of only one User Plane group.
• Operator can configure multiple User Planes in specific user-plane-group and in default group.
• User Planes which are associated with SAEGW-C but are not defined in any User Plane group are added
in default group.
• Operator can associate User Plane Group to APN and APN Profile.
• If there is no User Plane group associated to an APN then for Pure-P and Collapsed call, the SAEGW-C
uses default group to select User Plane for that session.
• If there is no User Plane group associated to APN Profile or no APN Profile is defined, then for Pure-S
calls SAEGW-C uses “default” user plane group.
• For PGW Multi-PDN call, same User Plane is selected.
• User Plane group associated with APN is also used while sending IP Pool chunks to User Plane. IP Pool
associated with APN is broken down to chunks and are available for distribution to all UPs from group
associated with APN.
• For user-plane-groups which are not associated with any APN, SAEGW-C does not send any IP Pool
chunks to UPs belonging to these group. This is applicable to default group also.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
114
 Cisco Confidential - Limited Release
APN and APN Profile-Based User Plane Selection for CUPS
Architecture

• Sessions with static IP address (IPv4/IPv6) are supported. The User Plane selection of static session is
fixed as per chunk allocation to User Plane from User Plane group associated to an APN.
• If same static IP address range is used across multiple APN, then it is recommended to use same User
Plane group in those APN.

Architecture
The following figure depicts a high-level architecture of this feature.

Session Recovery and ICSR

Sx-Demux Recovery, ICSR and Sessmgr and VPNmgr recovery is supported

Limitations
In CUPS architecture, this feature has the following known limitations:
• SAEGW-C does not support IPv4v6 PDN type call with static address received from UE, even if one of
the IP address (either IPv4 or IPv6, or both) is static address.
• SAEGW-C does not support “allow-static” type pool configuration.
• Multi-PDN call with static IP address allocation is not supported.

Licensing
This feature is license-controlled. Contact your Cisco Account representative for license related details.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
115
 Cisco Confidential - Limited Release
APN and APN Profile-Based User Plane Selection for CUPS
Configuring APN-Based UP Grouping

Configuring APN-Based UP Grouping

This section provides information about configurations available in support of this feature.
Prerequisites:
• Same IP context should be present at Control-Plane as well as in User-Plane.
• IP context name which is specified in APN configuration should be same at Control-Plane and User-Plane.

Configuring User Plane Group in Control Plane

New user-plane-group is defined at the global configuration mode which lists User Plane endpoints
1. User Plane Group name “default” is created by default. Operator can add and remove peer-node-id in
default group. Operator cannot delete user-plane-group “default
2. If Sx Association Setup Request is received for any User plane node-id which is not part of any defined
User Plane Group, it will be part of Default User Plane Group.

Configuring User Plane Group

Use the following CLI commands to configure User Plane endpoint group in Control Plane.
configure
[ no ] user-plane-groupgroup_name
end
Notes:
• Removal of user-plane-group will trigger Sx-Association release from Control Plane of individual peer
id from that group.

Configuring Peer Node ID and User Plane Node IP Address

Use the following configuration commands to configure time-based PCC rule.
configure
user-plane-group group_name
[ no ] peer-node-id { ipv4-address | ipv6-address }
end
Notes:
• Removal of peer-node-id will trigger Sx-Association Release from Control Plane for that peer id.

Verifying the User Plane Group

Use the following CLI command for verification.
show user-plane-group { all | name group_name }

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
116
 Cisco Confidential - Limited Release
APN and APN Profile-Based User Plane Selection for CUPS
Associating User Plane Group with APN

Associating User Plane Group with APN

It is desired that calls to a particular APN be connected to a certain group of user-planes based on some
predefined selection criteria. Operator can associate User Plane Group to APN Configuration.
User Plane group configured to APN is also used while sending IP Pool chunks to User Plane. If there is IP
Pool associated with APN, only then the chunks from that pool will be sent to all User Planes in this group.
User Plane Group configuration in APN is used to select User Plane for P-GW Pure-P and Collapsed Call.
If there is no specific group is configured in APN then “default” group will be used.

Configuring User Plane Group in APN

Use the following CLI commands to configure User Plane group in APN.
configure
context context_name
apn apn_name
[ no ] user-plane-group group_name
end
NOTE: In this EFT release, removal or change of user-plane-group from APN is not supported.

Verifying the User Plane Group in APN

Use the following CLI command for verification.
show apn name apn_name }

Method of Procedure (MOP) to Remove or Change User Plane Group from APN
When explicit user-plane-group is configured, or implicit default group is used, the SAEGW-C sends IP Pool
chunks from the pool that is configured (or global pool when there is no explicit pool configuration in APN)
to the user planes in the group.
If you want to change or remove user-plane-group associated to a APN, then it is recommended to follow this
MOP because, currently, there is no support of run time config change of user-plane-group in APN after User
Plane is associated with SAEGW-C.
Before changing user-plane-group in APN it is recommended to use the following CLI command to first
gracefully clear all existing calls belonging to user-plane-group associated with APN.
clear subscribers saegw-only user-plane-group group_name no-select-up
Executing this CLI command releases all sessions from User Plane belonging to the mentioned user-plane-group
gracefully, and marks that User Plane as "Not Available for Session Selection". This User Plane continues to
be in Associated state, but it will not be available for Session selection.
After clearing the session, execute either of the following CLI command on User Plane to remove its association
from Control Plane, and make required changes after UP association is released.
no user-plane-service service_name

Or:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
117
 Cisco Confidential - Limited Release
APN and APN Profile-Based User Plane Selection for CUPS
Associating User Plane Group with APN Profile

no peer-node-id { ipv4-address ipv4_address | ipv6-address ipv6_address}

Associating User Plane Group with APN Profile

To select User Plane for S-GW Pure-S calls, SAEGW-C uses user-plane-group associated with APN Profile
under Operator Policy. When APN profile do not have any user-plane-group associated or no APN profile
was used, then SAEGW-C will select User Plane from default user-plane-group.

Configuring User Plane Group in APN Profile

Use the following CLI commands to configure User Plane group in APN.
configure
apn-profile profile_name
[ no ] user-plane-group group_name
end

Monitoring and Troubleshooting APN-Based UP Grouping

The output of the following CLI commands has been enhanced in support of this feature.
• show sx peers
• Group Name Column in the output of this command is the name of user-plane-group under which
Peer is configured at Control Plane.
• Peer, which is not part of any group, will be added under user-plane-group “default”
• For user-plane-group which is not associated with any “apn”, SAEGW-C will not send any IP Pools
to User Planes from this group. And so, in the output of this command, the Group Name that is not
associated with and “apn”, the IP Pool status will be “N – Not Applicable”. Also, for User Planes
in this group, when “show sx peers” is executed on User Plane, it will show Peer ID as “0”.

• show ip user-plane
• show ip pool-chunks up-id up_id user-plane-group name up_group_name

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
118
 Cisco Confidential - Limited Release

CHAPTER 15
Cisco Ultra Traffic Optimization with VPP
• Revision History, on page 119
• Feature Description, on page 119
• RCM Support, on page 120
• Sending the GBR or MBR Values to Cisco Ultra Traffic Optimization , on page 120
• How it Works, on page 121
• Show Commands and Outputs, on page 122
• Sample Configuration, on page 128

Revision History
Revision Details Release

RCM support and sending of GBR and MBR values are added in this release. 21.22

First introduced. 21.20

This feature is not fully qualified in this release.

Feature Description
Cisco Ultra Traffic Optimization is supported on VPP in the CUPS architecture.
The Cisco Ultra Traffic Optimization is a RAN optimization technology that increases subscriber connection
speeds in congested cells and, as a result, increases the cell capacity significantly. The result is an optimized
RAN, where Mobile Network Operators (MNOs) can deploy fewer cells, on an ongoing basis, and absorb
more traffic growth while meeting network quality targets.
Large traffic flows, such as Adaptive Bit Rate (ABR) video, saturate radio resources and swamp the eNodeB
scheduler. The Cisco Ultra Traffic Optimization employs machine learning algorithms to detect large traffic
flows (such as video) in the network and optimize the delivery of those flows to mitigate the network congestion
without changing user quality (that is, video works the same for the end user). In other words, by employing
software intelligence at the network core, Cisco Ultra Traffic Optimization mitigates the overwhelming impact
video has on the RAN.
The resulting benefits are seen in congested network sites. The Cisco Ultra Traffic Optimization:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
119
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
RCM Support

• Increases average user throughput.

• Increases congested cell site capacity.
• Reduces scheduler latency.
• Maintains user quality of experience even when more users and more traffic share a cell.
• Is measured directly by eNodeB performance counters (for example, average UE throughput, scheduler
latency), which are the key performance indicators that are used for network capacity planning.
• Provides permanent savings in RAN investment requirements.
• Is integrated in the Cisco StarOS P-GW.
• Requires no new hardware or cabling complexity - it can be turned on for a market in an hour.
• Supports HTTP(s) and QUIC traffic.

Licensing
The Cisco Ultra Traffic Optimization with VPP is a licensed Cisco solution. Contact your Cisco account
representative for detailed information on specific licensing requirements. For information on installing and
verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter
in the System Administration Guide.

RCM Support
This feature enables the Redundancy and Configuration Management (RCM) support for the Cisco Ultra
Traffic Optimization (CUTO). All relevant configuration to enable the Cisco Ultra Traffic Optimization
(CUTO) using service scheme and application of the Cisco Ultra Traffic Optimization (CUTO) profile or
policy on User Plane is supported using RCM.

Sending the GBR or MBR Values to Cisco Ultra Traffic

Optimization
During the stream create/update, a bearer with valid QER and is GBR bearer, the respective bearer level
downlink GBR/MBR values are sent to Cisco Ultra Traffic Optimization (CUTO) library as lower or upper
limit values otherwise lower limit or upper limit values are zero. The values of lower limit and upper limit
are in Bits Per Second (BPS). Post RCM support, the P-GW sends the downlink flow level GBR and MBR
values instead of bearer level GBR and MBR to the optimization library. For GBR bearer, flow level GBR is
sent as lower limit and flow level MBR is sent as the upper limit to the Cisco Ultra Traffic Optimization
(CUTO) library. For non-GBR bearer 0 is sent as lower limit and flow level MBR is sent as upper limit to the
Cisco Ultra Traffic Optimization (CUTO) library. If the flow level MBR is greater than the APN-AMBR for
a non GBR bearer, traffic is throttled at APN-AMBR. In such a case APN-AMBR is sent as the upper limit
to the Cisco Ultra Traffic Optimization (CUTO) library. If there is no valid flow level MBR specific to the
flow, APN-AMBR is sent as the upper limit to the Cisco Ultra Traffic Optimization (CUTO) library.
Optimization library maintains logical flow based on 3-tuple (That is source IP, destination IP and protocol),
whereas the non-CUPS architecture considers a flow as 5-tuple (That is source IP, destination IP, source port,
destination port and protocol). Hence multiple non-CUPS architecture 5-tuple entries can belong to same

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
120
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Cisco Ultra Traffic Optimization Library Deinitialization

3-tuple entry in optimization library. The PG-W provides GBR and MBR values based on 5-tupple to the
optimization library. As part of this feature:
• Optimization library uses the minimum of all MBR values that belong to same 3-tuple entry as upper
limit.
• Optimization library uses maximum of all GBR values that belong to same 3-tuple entry as lower limit.

Cisco Ultra Traffic Optimization Library Deinitialization

This feature currently doesn’t support the Deinitialization. Deinitialization happens when the Cisco Ultra
Traffic Optimization (CUTO) license is removed from the system.

How it Works
Architecture
The following figure illustrates the architecture of Cisco Ultra Traffic Optimization on VPP in CUPS.

Cisco Ultra Traffic Optimization is split across Control Plane and User Plane.

CUTO-CTRL
• CUTO-CTRL receives guidance and requests from SMGR through the East-West API (EWAPI), through
which clients (SMGR instances) are registered and de-registered, and new streams/flows are created and
terminated.
• CUTO-CTRL manages a set of shared memory (SHM) tables using a North-South API (NSAPI) consisting
of Cisco-provided SHM infrastructure.
• It is through this SHM environment that CUTO-VPP can read and write content that is visible to both
CUTO-VPP and CUTO-CTRL.
• The SHM is used for all high volume, scalable/mutable content necessary for the high-performance
configuration and administration of the CUTO solution in VPP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
121
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Limitations

CUTO-VPP
• CUTO-VPP is the packet processing engine in the user plane.
• In fastpath, Cisco Ultra Traffic Optimization is applied to packets on a stream configured with its operation.
• Packets are sent from the Stream conduit to a particular CUTO-VPP operation, and after some potential
delay (0-N milliseconds), traffic is returned to the same Conduit.
• Packets are never dropped by the Cisco Ultra Traffic optimization application.

Limitations
The Cisco Ultra Traffic Optimization feature in CUPS has the following limitations:
• CUTO configuration changes done in Service Schema do not take effect immediately for existing flows.
• Cisco Ultra Traffic Optimization VPP global deinitialization is not supported.
• Dynamic memory allocation between SMGR and CUTO-VPP.
• Bearer-related triggers for enabling Cisco Ultra Traffic Optimization are not supported.
• Rule match change trigger must be configured for CUTO in CUPS.
• Disabling of Traffic optimization is not supported on 'loc-update' trigger.
• Enabling Cisco Ultra Traffic Optimization via Gx is not supported.
• Removal of CUTO license will not trigger global deinitialization. CUTO configurations must be removed
to disengage CUTO functionality for new flows.

Show Commands and Outputs

This section provides information regarding show commands and their outputs in support of Cisco Ultra
Traffic Optimization in CUPS.
For information on other supporting show commands, refer to Monitoring and Troubleshooting section under
the Cisco Ultra Traffic Optimization chapter in the P-GW Administration Guide.

Show Commands and Outputs

show user-plane-service traffic-optimization counters sessmgr all
The output of this command includes the following fields:
TCP Traffic Optimization Flows:
• Active Normal Flow Count
• Active Large Flow Count
• Active Managed Large Flow Count
• Active Unmanaged Large Flow Count

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
122
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Show Commands and Outputs

• Total Normal Flow Count

• Total Large Flow Count
• Total Managed Large Flow Count
• Total Unmanaged Large Flow Count
• Total IO Bytes
• Total Large Flow Bytes
• Total Recovered Capacity Bytes
• Total Recovered Capacity ms

UDP Traffic Optimization Flows:

• Active Normal Flow Count
• Active Large Flow Count
• Active Managed Large Flow Count
• Active Unmanaged Large Flow Count
• Total Normal Flow Count
• Total Large Flow Count
• Total Managed Large Flow Count
• Total Unmanaged Large Flow Count
• Total IO Bytes
• Total Large Flow Bytes
• Total Recovered Capacity Bytes
• Total Recovered Capacity ms

show user-plane-service traffic-optimization info

The output of this command includes the following fields:
• CUTO Ctrl Library Version
• CUTO VPP Library Version
• Mode
• Configuration

show user-plane-service traffic-optimization policy all

The output of this command includes the following fields:
• Policy Name
• Policy-Id

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
123
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Bulkstats

• Bandwidth-Mgmt
• Backoff-Profile
• Min-Effective-Rate
• Min-Flow-Control-Rate

• Curbing-Control:
• Time
• Rate
• Max-Phases
• Threshold-Rate

• Heavy-Session:
• Threshold
• Standard-Flow-Timeout

• Link-Profile:
• Initial-Rate
• Max-Rate
• Peak-Lock

• Session-Params:
• Tcp-Ramp-Up
• Udp-Ramp-Up

Bulkstats
The following existing bulk statistics are supported by Cisco Ultra Traffic Optimization in CUPS:

Bulk Statistics Description

cuto-uplink-drop Indicates the total number of uplink packets dropped by CUTO

library

cuto-uplink-hold Indicates the total number of uplink packets held by CUTO library

cuto-uplink-forward Indicates the total number of uplink packets forwarded by CUTO

library

cuto-uplink-rx Indicates the total number of uplink packets received by CUTO

library

cuto-uplink-tx Indicates the total number of uplink packets sent by CUTO library

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
124
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Bulkstats

Bulk Statistics Description

cuto-dnlink-drop Indicates the total number of downlink packets dropped by CUTO

library

cuto-dnlink-hold Indicates the total number of downlink packets held by CUTO

library

cuto-dnlink-forward Indicates the total number of downlink packets forwarded by CUTO

library

cuto-dnlink-rx Indicates the total number of downlink packets received by CUTO

library

cuto-dnlink-tx Indicates the total number of downlink packets sent by CUTO

library

cuto-todrs-generated Indicates the total number of TODRs generated.

tcp-active-normal-flow-count Indicates the number of TCP active-normal-flow count for Cisco

Ultra Traffic Optimization.

tcp-active-large-flow-count Indicates the number of TCP active-large-flow count for Cisco Ultra
Traffic Optimization.

tcp-active-managed-large-flow-count Indicates the number of TCP active-managed-large-flow count for

Cisco Ultra Traffic Optimization.

tcp-active-unmanaged-large-flow-count Indicates the number of TCP active-unmanaged-large-flow count

for Cisco Ultra Traffic Optimization.

tcp-total-normal-flow-count Indicates the number of TCP total-normal-flow count for Cisco

Ultra Traffic Optimization.

tcp-total-large-flow-count Indicates the number of TCP total-large-flow count for Cisco Ultra
Traffic Optimization.

tcp-total-managed-large-flow-count Indicates the number of TCP total-managed-large-flow count for

Cisco Ultra Traffic Optimization.

tcp-total-unmanaged-large-flow-count Indicates the number of TCP total-unmanaged-large-flow count for

Cisco Ultra Traffic Optimization.

tcp-total-io-bytes Indicates the number of TCP total-IO bytes for Cisco Ultra Traffic
Optimization.

tcp-total-large-flow-bytes Indicates the number of TCP total-large-flow bytes for Cisco Ultra
Traffic Optimization.

tcp-total-recovered-capacity-bytes Indicates the number of TCP total-recovered capacity bytes for

Cisco Ultra Traffic Optimization.

tcp-total-recovered-capacity-ms Indicates the number of TCP total-recovered capacity ms for Cisco

Ultra Traffic Optimization.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
125
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Bulkstats

Bulk Statistics Description

udp-active-normal-flow-count Indicates the number of UDP active-normal-flow count for Cisco

Ultra Traffic Optimization.

udp-active-large-flow-count Indicates the number of UDP active-large-flow count for Cisco

Ultra Traffic Optimization.

udp-active-managed-large-flow-count Indicates the number of UDP active-managed-large-flow count for

Cisco Ultra Traffic Optimization.

udp-active-unmanaged-large-flow-count Indicates the number of UDP active-unmanaged-large-flow count

for Cisco Ultra Traffic Optimization.

udp-total-normal-flow-count Indicates the number of UDP total-normal-flow count for Cisco

Ultra Traffic Optimization.

udp-total-large-flow-count Indicates the number of UDP total-large-flow count for Cisco Ultra
Traffic Optimization.

udp-total-managed-large-flow-count Indicates the number of UDP total-managed-large-flow count for

Cisco Ultra Traffic Optimization.

udp-total-unmanaged-large-flow-count Indicates the number of UDP total-unmanaged-large-flow count

for Cisco Ultra Traffic Optimization.

udp-total-io-bytes Indicates the number of UDP total-IO bytes for Cisco Ultra Traffic
Optimization.

udp-total-large-flow-bytes Indicates the number of UDP total-large-flow bytes for Cisco Ultra
Traffic Optimization.

udp-total-recovered-capacity-bytes Indicates the number of UDP total-recovered capacity bytes for

Cisco Ultra Traffic Optimization.

udp-total-recovered-capacity-ms Indicates the number of UDP total-recovered capacity ms for Cisco

Ultra Traffic Optimization.

The following statistics for Cisco Ultra Traffic Optimization, that are part of the legacy (StarOS)
implementation, are not applicable to the CUPS implementation.
• tcp-uplink-drop
• tcp-uplink-hold
• tcp-uplink-forward
• tcp-uplink-forward-and-hold
• tcp-uplink-hold-failed
• tcp-uplink-bw-limit-flow-sent
• tcp-dnlink-drop
• tcp-dnlink-hold

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
126
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Bulkstats

• tcp-dnlink-forward
• tcp-dnlink-forward-and-hold
• tcp-dnlink-hold-failed
• tcp-dnlink-bw-limit-flow-sent
• tcp-dnlink-async-drop
• tcp-dnlink-async-hold
• tcp-dnlink-async-forward
• tcp-dnlink-async-forward-and-hold
• tcp-dnlink-async-hold-failed
• tcp-process-packet-drop
• tcp-process-packet-hold
• tcp-process-packet-forward
• tcp-process-packet-forward-failed
• tcp-process-packet-forward-and-hold
• tcp-process-packet-forward-and-hold-failed
• tcp-pkt-copy
• tcp-pkt-Copy-failed
• tcp-process-pkt-copy
• tcp-process-pkt-copy-failed
• tcp-process-pkt-no-packet-found-action-forward
• tcp-process-pkt-no-packet-found-forward-and-hold
• tcp-process-pkt-no-packet-found-action-drop
• tcp-todrs-generated
• udp-uplink-drop
• udp-uplink-hold
• udp-uplink-forward
• udp-uplink-forward-and-hold
• udp-uplink-hold-failed
• udp-uplink-bw-limit-flow-sent
• udp-dnlink-drop
• udp-dnlink-hold
• udp-dnlink-forward

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
127
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Sample Configuration

• udp-dnlink-forward-and-hold
• udp-dnlink-hold-failed
• udp-dnlink-bw-limit-flow-sent
• udp-dnlink-async-drop
• udp-dnlink-async-hold
• udp-dnlink-async-forward
• udp-dnlink-async-forward-and-hold
• udp-dnlink-async-hold-failed
• udp-process-packet-drop
• udp-process-packet-hold
• udp-process-packet-forward
• udp-process-packet-forward-failed
• udp-process-packet-forward-and-hold
• udp-process-packet-forward-and-hold-failed
• udp-pkt-copy
• udp-pkt-Copy-failed
• udp-process-pkt-copy
• udp-process-pkt-copy-failed
• udp-process-pkt-no-packet-found-action-forward
• udp-process-pkt-no-packet-found-forward-and-hold
• udp-process-pkt-no-packet-found-action-drop
• udp-todrs-generated

Sample Configuration
Sample configuration to enable CUPS CUTO feature:
configure
active-charging service ACS
trigger-action TA1
traffic-optimization policy custom1
#exit
trigger-condition TC1
rule-name = dynamic-rule2
#exit
service-scheme SS1
trigger rule-match-change
priority 5 trigger-condition TC1 trigger-action TA1
#exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
128
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Sample Configuration

subs-class SB1
rulebase = cisco
#exit
subscriber-base default
priority 5 subs-class SB1 bind service-scheme SS1
#exit
traffic-optimization-profile
mode active
data-record
#exit
traffic-optimization-policy custom1
bandwidth-mgmt min-effective-rate 300 min-flow-control-rate 150
heavy-session threshold 200000
link-profile max-rate 20000
#exit
traffic-optimization-policy default
#exit
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
129
 Cisco Confidential - Limited Release
Cisco Ultra Traffic Optimization with VPP
Sample Configuration

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
130
 Cisco Confidential - Limited Release

CHAPTER 16
Disable Radius Accounting
• Revision History, on page 131
• Feature Description, on page 131
• Configuring RADIUS Accounting on Dedicated Bearer Feature, on page 132

Revision History
Table 2: Revision History

Revision Details Release

First Introduced 21.19

Feature Description
RADIUS is a distributed client or server system that secures networks against unauthorized access. In the
Cisco implementation, the RADIUS clients run on Cisco devices and send authentication requests to a central
RADIUS server that contains all user authentication and network service access information.
CUPS supports disabling RADIUS accounting on dedicated bearers for RADIUS server.
CUPS supports the following functionality:
• Enabling RADIUS accounting for all bearers
• Disabling RADIUS accounting for a specific dedicated bearer based on its QCI and ARP value
• Enabling RADIUS accounting only for the default bearer while disabling RADIUS accounting for all
the dedicated bearers
• URRs are not created for bearers that have their RADIUS accounting disabled
• CLI configuration changes apply only to new calls made after the configuration change and do not affect
existing calls.
• If the RADIUS accounting for a particular bearer is disabled or enabled, it applies to bearers created after
it was disabled or enabled, and not for existing bearers

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
131
 Cisco Confidential - Limited Release
Disable Radius Accounting
Configuring RADIUS Accounting on Dedicated Bearer Feature

NOTE: This functionality is also available for products that use RADIUS in non-CUPS architecture.

Configuring RADIUS Accounting on Dedicated Bearer Feature

This section describes the CLI configurations for:
• Enabling RADIUS accounting for all bearers
• Disabling RADIUS accounting for a specific dedicated bearer based on its QCI and ARP value
• Enabling RADIUS accounting only for the default bearer while disabling RADIUS accounting for all
the dedicated bearers

Enabling RADIUS Accounting for All Bearers

To enable RADIUS accounting for all the bearers, use the following CLI configuration.

configure
context context_name
aaa group group_name
radius accounting mode all-bearers
end
NOTES:
• The radius accounting mode all-bearers CLI command is enabled by default.

Disabling RADIUS Accounting for a Specific Bearer

To disable RADIUS accounting for a specific dedicated bearer based on its QCI and ARP values, use the
following CLI configuration.

configure
context context_name
aaa group group_name
radius accounting disable-bearer qci qci_value arp-priority-level
arp_value
end
NOTES:
• The radius accounting disable-bearer qci qci_value arp-priority-level arp_value CLI command
disables RADIUS accounting only for the dedicated bearer with the specified QCI and ARP values.
Accounting of other dedicated bearers is not affected.
• The maximum number of QCI and ARP combination configurations allowed to disable RADIUS
accounting on dedicated bearers is 16. If you try to configure more than 16 combinations, the following
error message is displayed:

Failure: Error!!! Maximum 16 qci and arp combinations allowed.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
132
 Cisco Confidential - Limited Release
Disable Radius Accounting
Enabling RADIUS Accounting only for the Default Bearer

Enabling RADIUS Accounting only for the Default Bearer

To enable RADIUS accounting only for the default bearer, and disable RADIUS accounting for all the dedicated
bearers, use the following CLI configuration.

configure
context context_name
aaa group group_name
radius accounting mode default-bearer-only
end
NOTES:
• The radius accounting mode default-bearer-only CLI command enables RADIUS accounting only
for the default bearer and disables RADIUS accounting for all the dedicated bearers.
• To remove the radius accounting disable-bearer qci qci_value arp-priority-level arp_value
configuration for a specific dedicated bearer, and allow RADIUS accounting for that dedicated bearer,
use the no radius accounting disable-bearer qci qci_value arp-priority-level arp_value CLI command.
• When RADIUS accounting mode is set to default-bearer-only, you cannot disable RADIUS accounting
on a dedicated bearer. If you run the radius accounting disable-bearer qci qci_value arp-priority-level
arp_value CLI command, the following error message is displayed:

Failure: Error!!! Radius accounting mode is set to default-bearer-only. Change the mode
to all-bearers and run this CLI again

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
133
 Cisco Confidential - Limited Release
Disable Radius Accounting
Enabling RADIUS Accounting only for the Default Bearer

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
134
 Cisco Confidential - Limited Release

CHAPTER 17
Default and Dedicated Bearer Support for Pure-P
and Collapsed Sessions
• Revision History, on page 135
• Feature Description, on page 135

Revision History
Revision Details Release

In this release, enhancement related to S-GW, MME and eNodeB handovers 21.14 (5/31/2019)
are added to this feature.

In this release, basic support for ADC over dedicated bearers, and IDLE 21.13 (2/26/2019)
to ACTIVE mode transition (SAEGW, DDN) support for dedicated bearers
are added.

First introduced. 21.12 (1/31/2019)

This feature is not fully qualified in this release.

Feature Description
Provides a foundation for contributing towards improved Quality of User Experience (QoE) by enabling
deterministic end to-end forwarding and scheduling treatments for different services or classes of applications
pursuant to their requirements for committed bandwidth resources, jitter and delay. In this way, each application
receives the service treatment that users expect.
The Cisco EPC core platforms support one or more EPS bearers (default plus dedicated). An EPS bearer is a
logical aggregate of one or more Service Data Flows (SDFs), running between a UE and a P-GW in the case
of a GTP-based S5/S8 interface, and between a UE and HSGW (HRPD Serving Gateway) in case of a
PMIP-based S2a interface. In networks where GTP is used as the S5/S8 protocol, the EPS bearer constitutes
a concatenation of a radio bearer, S1-U bearer and an S5/S8 bearer anchored on the P-GW. In cases where
PMIPv6 is used the EPS bearer is concatenated between the UE and HSGW with IP connectivity between
the HSGW and P-GW.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
135
 Cisco Confidential - Limited Release
Default and Dedicated Bearer Support for Pure-P and Collapsed Sessions
Supported Functionality

An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and
P-GW in the GTP-based S5/S8 design, and between a UE and HSGW in the PMIPv6 S2a approach. If different
QoS scheduling priorities are required between Service Data Flows, they should be assigned to separate EPS
bearers. Packet filters are signaled in the NAS procedures and associated with a unique packet filter identifier
on a per-PDN connection basis.
One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the
lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer
is referred to as the default bearer. A PDN connection represents a traffic flow aggregate between a mobile
access terminal and an external Packet Data Network (PDN) such as an IMS network, a walled garden
application cloud or a back-end enterprise network. Any additional EPS bearer that is established to the same
PDN is referred to as a dedicated bearer. The EPS bearer Traffic Flow Template (TFT) is the set of all 5-tuple
packet filters associated with a given EPS bearer. The EPC core elements assign a separate bearer ID for each
established EPS bearer. At a given time a UE may have multiple PDN connections on one or more P-GWs.
With this feature, UDP, TCP, and HTTP data is offloaded to Fastpath for Default and Dedicated bearer.

Supported Functionality
For Pure-P and Collapsed session, the:
1. Default bearer establishment includes (CCA-I):
• Default bearer establishment with and without rule.
• Predefined Rules/Group-of-Ruledefs (GoRs).

2. Default bearer updation includes (CCA-U/RAR):

• New Rule installation.
• Modification of existing rules (TFT change, MBR/GBR change, Flow Status change).
• Removal of existing rules.
• Default Bearer QoS change.
• APN-AMBR change.
• Predefined Rules/GoRs.

3. Default bearer deletion includes (CCA-U/RAR):

• Removal of existing rules.

4. Dedicated bearer establishment includes (CCA-I/CCA-U/RAR):

• New dedicated bearer establishment.
• Predefined Rules/GoRs.

5. Dedicated bearer updation includes (CCA-U/RAR):

• Addition of new rule on already installed dedicated bearer.
• Modification of existing rules (TFT change, MBR/GBR change).
• Removal of existing rules.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
136
 Cisco Confidential - Limited Release
Default and Dedicated Bearer Support for Pure-P and Collapsed Sessions
Limitations

• Rule QCI change.

• Predefined Rules/GoRs
• Basic Support for ADC over dedicated bearers
• IDLE to ACTIVE mode transition (SAEGW, DDN) support for dedicated bearers.

6. Dedicated bearer deletion includes:

• Deletion of dedicated bearer through MME/PCRF and clear subscribers imsi imsi_id ebi ebi_id
CLI command.

7. During session recovery for Pure-P and Collapsed session at User Plane, charging data is recovered for
User Plane.
8. MME and eNodeB Handovers (HO):
• Pure-P Call Type:
• MME and eNodeB HO with and without new policy (Create, Update, Delete, and any
combination of Create, Update, and Delete) from Gx.

• Collapsed Call Type:

• MME and eNodeB HO with and without new policy (Create, Update, and Delete) from Gx.

9. S-GW Handovers (HO):

• Pure-P to Pure-P HO:
• Pure-P to Pure-P HO with and without dedicated bearer with new policy (Create, Update, Delete,
and any combination of Create, Update, and Delete) from Gx.
• Pure-P to Pure-P HO with bearer marked for deletion during HO.

• Collapsed to Pure-P and Pure-P to Collapsed HO:

• Collapsed to Pure-P and Pure-P to Collapsed HOs without dedicated bearer with new policy
(Install new rule, modify default bearer QCI, update, or remove rule) from Gx.
• Collapsed to Pure-P and Pure-P to Collapsed HOs with dedicated bearer without new policy
from Gx.

Limitations
In this release, the following functionality are not supported:
• Updation of dynamic rule precedence installed on default bearer.
• Time-based activation and deactivation of rules on default and dedicated bearer.
• Collision Handling is not yet supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
137
 Cisco Confidential - Limited Release
Default and Dedicated Bearer Support for Pure-P and Collapsed Sessions
Limitations

Collisions can happen between Control messages from PCRF and from Access side. Multiple procedures
in a single PCRF initiated message (CCA-U/RAR) leads to uncontrolled collisions. For example, Creation
of a Bearer along with Deletion of another Bearer in same RAR.
• Mid-session update and/or modification of ADC rules—whether change in configuration or PDN update
over RAR, is not supported.
• MME and eNodeB Handovers (HO):
• Pure-P Call Type:
• Any failure handling or Collisions occurring during HO.

• Collapsed Call Type:

• MME and eNodeB HO with new policy (any combination of create, update, and delete together)
from Gx.
• Any failure handling or Collisions occurring during HO.

• S-GW Handovers (HO):

• Pure-P to Pure-P HO:
• Any failure handling or Collisions occurring during HO.
• Dynamic rule QCI change installed on dedicated bearer such that its bearer EBI is not changed.

• Collapsed to Pure-P and Pure-P to Collapsed HO:

• Any failure handling or Collisions occurring during HO.
• Collapsed to Pure-P and Pure-P to Collpased HOs with dedicated bearer with any new/update
policy from Gx.
• Pure-P to Collapsed and Collapsed to Pure-P Handover with dedicated bearer is not supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
138
 Cisco Confidential - Limited Release

CHAPTER 18
DSCP Markings For Collapse Calls
• Feature Summary and Revision History, on page 139
• Feature Description, on page 139
• How It Works, on page 140
• Configuration, on page 140
• Monitoring and Troubleshooting, on page 141
• Show Commands Outputs, on page 141
• SMGR CP Changes, on page 141

Feature Summary and Revision History

Revision History

Table 3: Revision Table

Revision Release
Details
First 21.20.3
introduced

Feature Description
Currently QCI-based DSCP markings are applicable for Pure-S and Pure-P calls. The DSCP markings are
based on QCI-QOS-Mapping associated with respective S-GW service or P-GW service. For collapse calls
QCI-QOS-Mapping associated with PGW-service is applicable. This feature helps to apply the DSCP markings
for collapse calls based on associated S-GW and P-GW services for uplink and downlink traffic. For uplink
traffic DSCP markings associated with logical P-GW service is applicable. For downlink traffic DSCP markings
associated with logical S-GW service is applicable. The DSCP markings are present in IP header of data traffic
as a part of GTPU header and Inner IP. There’s option to enabled or disable this functionality by CLI
configuration. When you enable the feature, then only the new functionality is applicable otherwise existing
functionality also works. By default, this feature is disabled so that there’s no impact on customers who
upgrades to this feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
139
 Cisco Confidential - Limited Release
DSCP Markings For Collapse Calls
How It Works

How It Works
Following are the steps that describes the DSCP markings for the collapse calls.
• In case of Collapse call:
• for ACCESS side QCI-QOS mapping table associated with SGW-service is used.
• For CORE side QCI-QOS mapping table associated with PGW-service is used.

• This is applicable once you enable the feature, otherwise QCI-QOS mapping table associated with
PGW-service is used for both sides.
• APN associated QCI-QOS mapping table is preferred over the P-GW service QCI-QOS mapping table.
• APN-Profile associated QCI-QOS mapping table is preferred over SGW-Service QCI-QOS mapping
table for ACCESS side DSCP markings.
• In case only P-GW service has QCI-QOS mapping table configuration then these DSCP markings is
applicable on both ACCESS & CORE side for collapse call.
• In case only S-GW service has QCI-QOS mapping table configuration then these DSCP markings is
applicable on ACCESS side for collapse call.
• There is a new configurable parameter inside the SAE-GW service which indicates whether the feature
is enabled or disable.
• For Pure-P to Collapse HO and vice-versa, transport layer markings are updated in FAR as a part of Sx
Modify request.
• Layer2 markings are also modified based on QCI-QOS mapping table picked for ACCESS & CORE
side.
• DSCP markings continues to apply on existing bearers post session recovery.
• DSCP markings continues for the bearers on standby chassis once it switches to active mode.

Configuration
Configure the following command inside the SAE-GW service to enable/disable this feature.
configure
context egress
saegw_service saegw_service
downlink-dscp-per-call-type enabled/disabled
end

Note When you enable the feature, use the S-GW service QCI-QOS mapping DSCP markings for downlink, if call
type collapses. By default, the downlink-DSCP-per-call-type is Disabled.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
140
 Cisco Confidential - Limited Release
DSCP Markings For Collapse Calls
Monitoring and Troubleshooting

Monitoring and Troubleshooting

This section provides information on CLI commands that are available for monitoring and troubleshooting
for DSCP markings for collapse calls.

Show Commands Outputs

This section provides information about show CLI commands that are available in support of DSCP markings
for collapse calls.

show saegw-service all

This show command is to check if the feature is enabled or Disabled.
Service name : SAEGW11
Service-Id : 47
Context : EPC1
Status : STARTED
sgw-service : SGW11
pgw-service : PGW11
sx-service : SX11C
User Plane Tunnel GTPU Service : SAEGW11SXU
Newcall policy : n/a
downlink-dscp-per-call-type : enabled
CUPS Enabled : Yes
Service name : SAEGW21
Service-Id : 25
Context : EPC2
Status : STARTED
sgw-service : SGW21
pgw-service : PGW21
sx-service : SX21C
User Plane Tunnel GTPU Service : SAEGW21SXU
Newcall policy : n/a
downlink-dscp-per-call-type : disabled
CUPS Enabled : Yes

show sub user-plane-only callid <call_id> far full all

Use this User Plane CLIs to validate the Transport level marking options and inner packet markings for
UPLINK/DOWNLINK FAR.

SMGR CP Changes
DSCP markings for Uplink/CORE and Downlink/ACCESS are present at bearer level inside
sessmgr_sub_session_t → sessmgr_qci_tab_t.
User datagram DSCP markings are updated in IP header of inner packet, that is packet sent from UE to Internet
and vice/versa.
Encaps header DSCP markings are updated in IP header of outer IP layer having GTPU-header (Outer header).
DSCP markings are sent from CP to UP inside FAR IE as follows:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
141
 Cisco Confidential - Limited Release
DSCP Markings For Collapse Calls
SMGR CP Changes

• Transport Level Marking - The DSCP markings is configured in encaps header for ACCESS side and
User-datagram on CORE side for collapse call.
• Transport Level Marking Options - Includes two options and are applicable only for outer header:
• Copy-inner: Copy the inner packets markings to outer header
• Copy-outer: Relay the DSCP markings for outer header

Inner Packet Marking - DSCP markings is configured in user datagram for ACCESS side. For CORE side it
is N/A for collapse call.
Logic to fetch the DSCP marking changed for collapse call:
• Fetch the DSCP markings based on qci & qrp_pl for session from the associated SGW-Service for
ACCESS/downlink side.
• Fetch the DSCP markings based on qci & qrp_pl for session from the associated PGW-Service for
CORE/uplink side.
• For ACCESS/downlink side qci-qos mapping table associated with APN-profile takes preference over
SGW-Service qci-qos-mapping table.
• For CORE/uplink side qci-qos mapping table associated with APN config takes preference over
PGW-Service qci-qos-mapping table.
• In case SGW-service qci-qos mapping table is not configured, then PGW-service qci-qos-mapping table
is applied on both ACCESS/CORE side.
• In case PGW-service qci-qos mapping table is not configured, then SGW-service qci-qos mapping tabled
is applied on ACCESS side and no DSCP markings applied on CORE side.
• DSCP markings are updated on UP in create/update FAR sent as a part of SX Establishment/Modification
request from CP to UP.
• Update the TLM, IPM & TLMO in case of HO from Pure-P to Collapse and vice-versa in Sx Modification
request as a part of Update FAR IE.
• Update the layer2 markings in case of HO from Pure-P to Collapse and vice-versa in Sx Modification
request as a part of Update FAR IE.

Following table depicts the various possible config combinations and outcome for DSCP markings to be
applied on ACCESS and CORE side for COLLAPSE call:

S. Feature PGW Service SGW Service APN QOS-QCI APN-Profile ACCESS/Downlink CORE/Uplink
No. Enable/Disable QOS-QCI QOS-QCI table QOS-QCI DSCP Markings DSCP Markings
table table configured(Q3) table for Collapse Call for Collapse Call
configured(Q1) configured(Q2) configured(Q4)
1 ENABLE YES YES YES YES Q4 (APN-Profile) Q3(APN)
2 ENABLE YES YES YES NO Q2 Q3(APN)
(SGW-Service)
3 ENABLE YES YES NO YES Q4 (APN-Profile) Q1(PGW-service)
4 ENABLE YES YES NO NO Q2 Q1(PGW-service)
(SGW-Service)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
142
 Cisco Confidential - Limited Release
DSCP Markings For Collapse Calls
SMGR CP Changes

S. Feature PGW Service SGW Service APN QOS-QCI APN-Profile ACCESS/Downlink CORE/Uplink
No. Enable/Disable QOS-QCI QOS-QCI table QOS-QCI DSCP Markings DSCP Markings
table table configured(Q3) table for Collapse Call for Collapse Cal
configured(Q1) configured(Q2) configured(Q4)
5 ENABLE YES NO YES YES Q4 (APN-Profile) Q3(APN)
6 ENABLE YES NO YES NO Q3(APN) Q3(APN)
7 ENABLE YES NO NO YES Q4 (APN-Profile) Q1(PGW-service
8 ENABLE YES NO NO NO Q1(PGW-service) Q1(PGW-service
9 ENABLE NO YES YES YES Q4 (APN-Profile) Q3(APN)
10 ENABLE NO YES YES NO Q2 Q3(APN)
(SGW-Service)
11 ENABLE NO YES NO YES Q4 (APN-Profile) N/A (NO DSCP
12 ENABLE NO YES NO NO Q2 N/A (NO DSCP
(SGW-Service)
13 ENABLE NO NO YES YES Q4 (APN-Profile) Q3(APN)
14 ENABLE NO NO YES NO Q3(APN) Q3(APN)
15 ENABLE NO NO NO YES Q4 (APN-Profile) N/A (NO DSCP
16 ENABLE NO NO NO NO N/A (NO DSCP) N/A (NO DSCP
17 DISABLE YES YES YES YES Q3(APN) Q3(APN)
18 DISABLE YES YES YES NO Q3(APN) Q3(APN)
19 DISABLE YES YES NO YES Q1(PGW-service) Q1(PGW-service
20 DISABLE YES YES NO NO Q1(PGW-service) Q1(PGW-service
21 DISABLE YES NO YES YES Q3(APN) Q3(APN)
22 DISABLE YES NO YES NO Q3(APN) Q3(APN)
23 DISABLE YES NO NO YES Q1(PGW-service) Q1(PGW-service
24 DISABLE YES NO NO NO Q1(PGW-service) Q1(PGW-service
25 DISABLE NO YES YES YES Q3(APN) Q3(APN)
26 DISABLE NO YES YES NO Q3(APN) Q3(APN)
27 DISABLE NO YES NO YES N/A (NO DSCP) N/A (NO DSCP
28 DISABLE NO YES NO NO N/A (NO DSCP) N/A (NO DSCP
29 DISABLE NO NO YES YES Q3(APN) Q3(APN)
30 DISABLE NO NO YES NO Q3(APN) Q3(APN)
31 DISABLE NO NO NO YES N/A (NO DSCP) N/A (NO DSCP
32 DISABLE NO NO NO NO N/A (NO DSCP) N/A (NO DSCP

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
143
 Cisco Confidential - Limited Release
DSCP Markings For Collapse Calls
SMGR CP Changes

Statistics
Use the following User Plane CLI to show the number of TOS marked packets for U/L and D/L.
show sub user-plane-only full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
144
 Cisco Confidential - Limited Release

CHAPTER 19
Dynamic and ADC Charging Rule Names
• Revision History, on page 145
• Feature Description, on page 145

Revision History
Revision Details Release

First introduced. 21.12 (1/29/2019)

This feature is not fully qualified in this release.

Feature Description
With this feature, the Operators can support Mobility Services Platform (MSP) functional use cases.
This feature covers the following requirements:
• Support of 64 rules is for:
• Dynamic rules on default bearer with flow descriptions.
• ADC rules with and without flow descriptions.

• Up to 174 PDRs, and it’s corresponding FARs, URRs and QERs, are supported for static rules, predefined
rules, dynamic rules, and ADC rules.
• All rules information is communicated to User Plane using Create PDR, Create URR, Create FAR and
Create QER.
• All Sx messages supports the required number of PDR, URR, FAR, QER and Usage report, Query URR.
• Monitor protocol displays all Sx messages.
• Monitor subscriber displays all Sx messages.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
145
 Cisco Confidential - Limited Release
Dynamic and ADC Charging Rule Names
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
146
 Cisco Confidential - Limited Release

CHAPTER 20
Dynamic APN and IP Pool Support
• Revision History, on page 147
• Feature Description, on page 147
• How It Works, on page 147
• Configuring Dynamic APN and IP Pool Support, on page 149

Revision History
Revision Details Release

First introduced. 21.19

Feature Description
The Dynamic APN and IP Pool Support feature enables the following functionality:
• Addition of an IP pool in an APN that previously had no IP pool configurations.
• Modification or removal of an existing IP pool configuration in an APN and adding a different one.
• Deletion or removal of existing IP pool configurations in an APN.

This feature supports dynamic configuration changes of the APN IP pools and groups and allocates the chunk
to the User Plane (UP) without Sx reassociation.

How It Works
This section provides a brief of how the Dynamic APN and IP Pool Support feature works.
The Demux conveys the dynamically added APN and IP pool configuration to the VPN Manager. This
information ensures the allocation of resources without Sx link breakage. The Control Plane (CP) then pushes
the configuration to the User Plane via the Sx-Association Update message.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
147
 Cisco Confidential - Limited Release
Dynamic APN and IP Pool Support
How It Works

Dynamically Triggering APN IP Pool Addition Request

You can add APN and IP pools associated to new or existing APNs dynamically. During runtime, the new
APNs and IP pools are added to the configuration. The configuration update occurs without causing any break
in the Sx association between CP and UP,
The Dynamic APN and IP Pool Support feature also supports the following functionality:
• Addition of new IP pools or UP groups to existing APNs
• Addition of new APN to existing UP groups

This feature supports the following scenarios:

Operation on APN Operation on IP Operation on UP Group Impact on existing calls

Pool/Group

Addition of new APN New pool or new group New UP group (not No impact
registered)

Addition of new APN New pool or new group Existing UP group No impact
(already few UP
registered)

Addition of new APN Defaults pool Existing UP group No impact

(already few UP
registered)

Existing APN Remove existing IP pool Existing UP group No further allocation from
or group and add new IP (already few UP the removed IP pool. No
pool or group registered) impact on calls.

Existing APN Remove existing IP pool Default UP group No further allocation from
or group and add new IP the removed IP pool. No
pool or group impact on calls.

Existing APN Remove existing IP pool Default UP group No further allocation from
or group from APN the removed IP pool. No
impact on calls.

Removing APN Pass the new set of IP Existing UP group All existing calls
pools or groups to (already few UP associated to that APN
VPNMgr-C for each registered) aren’t affected but no new
impacted UP calls are connected.

Figure 7: Dynamic Addition of APN and IP Pools

After the newly added UP registration is successful, the VPN manager pushes the IP chunk information to
the UP from the pool.
• The CP Sx-demux receives the trigger from the CLI for adding, modifying, or deleting a new APN or
IP pools.
• The Sx-C demux on the CP determines the list of impacted UPs. It passes on the information for each
impacted UP to the VPN manager at the CP using the Modify APN IP Pool Request.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
148
 Cisco Confidential - Limited Release
Dynamic APN and IP Pool Support
Limitations

• The VPN manager allocates the IP chunks and replies with a success or failure to the Sx-C demux.
• The new APN or IP pool is applied to the existing configuration. Use the “show config” CLI command
to view the configuration.
• The addition of a new IP pool name or UP group to an existing APN does not affect the existing calls
on that APN.
• Any IP pool (either IPv4 or IPv6) can be added to APN dynamically and can be modified (deleted and
a new IP pool is added) in the same run. This change does not impact the existing calls in any way. The
changed configuration applies only after the new calls to the APN are made.
• If any calls are running on a specific APN, any attempt to deleting that APN throws an error.
• Only APN that have no calls running can be deleted. The IP pools chunks associated to this APN are
available for use to other APNs.

Passing of Allocated Chunks Information to the UP

• On receiving an Sx Association Update Request or Response message, the proprietary or custom IE
pushes the IP chunk information to the UP.
• The S1-U demux on the UP passes on this information to the VPN manager on the UP
• The VPN manager receives the BGP routes, which it announces on a per chunk basis.

Limitations
The Dynamic APN and IP Pool Support feature has the following limitations:
• Any operation on IP pools and UP group associated to existing APN is not supported in this release.
• Multiple UPs won’t be able to access the same IP pool as a part of this release.
• If a new UP_GROUP is added against an APN without configuring any new IP pool, then the calls start
landing on the new UP_GROUP rather than the default one. This causes the calls to get aborted.

Configuring Dynamic APN and IP Pool Support

This section describes how to configure the Dynamic APN and IP Pool Support feature.
Follow this sequence of commands to add a new APN (addition of the IP pool is optional).
• Create a new IP pool. For more informattion, see the ip address ip_ pool_name CLI command in the
Command Reference Guide.
To add an IP pool to an IP pool group, use the ip pool ip_pool_name static group-name
ip_pool_group_name CLI command. For more information, see the Command Reference Guide.
• Add a new APN and associate the new IP pool to this APN. For more informattion, see the apn apn_name
CLI command in the Command Reference Guide.
To add an IP Pool group to the APN, use the ip address pool name ip_pool_group_name CLI command.
For more information, see the Command Reference Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
149
 Cisco Confidential - Limited Release
Dynamic APN and IP Pool Support
Updating the APN Configuration

• Push the configuration to the UP.

• Update the IP pool information to the VPN manager.
• Run an attach call.

Updating the APN Configuration

Use the following command in Exec mode to update the VPN manager with the APN configuration changes.
To update all the configured APNs to the VPN manager:
update ip-pool apn all
end
To update a specific APN configuration to the VPN manager:
update ip-pool apn name apn_name
end
NOTES:
• This CLI command triggers the SX_ASSOCIATION_UPDATE towards the UP and transfers all the
allocated IP pool chunks for the newly added IP pools.

Example
The following CLI command updates a specific APN configuration to the VPN manager:
update ip-pool apn name cisco.com

Verifying Dynamic APN and IP Pool Support

Use the following command to verify the Dynamic APN and IP Pool Support feature.
show config apn intershat
The following is a sample output of the show command:
config
context ingress
apn intershat
pdp-type ipv4 ipv6
bearer-control-mode mixed
selection-mode subscribed sent-by-ms chosen-by-sgsn
ims-auth-service ims-ggsn-auth
ip access-group acl4-1 in
ip access-group acl4-1 out
ip context-name egress
ip address pool name ipv4-test
ipv6 access-group acl6-1 in
ipv6 access-group acl6-1 out
active-charging rulebase prepaid
exit
#exit
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
150
 Cisco Confidential - Limited Release

CHAPTER 21
Dynamic User Plane Selection
• Revision History, on page 151
• Feature Description, on page 151

Revision History
Revision Details Release

First introduced. 21.18.1

Feature Description
In a Multi-access Edge Computing (MEC) architecture, selecting an edge User Plane (UP) is key to providing
low latency and maximum bandwidth efficiency. The location information of the user equipment (UE) is used
to select an UP. For selecting an edge UP, two levels of granularity are considered, they are as follows:
• E-UTRAN Cell Global Identifier (ECGI) or Cell Global Identification (CGI) offers the lowest level of
granularity.
• Tracking Area Identifier (TAI) or Routing Area Identity (RAI) offers the next level of granularity.

Architecture
To select a UP based on the location parameter of the upcoming session, a DNS Name Authority Pointer
(NAPTR) query including TAI/RAI or ECGI/CGI is sent to the DNS Server. The DNS (NAPTR) Response
contains a list of UP IPs. To select an UP from this list, a Load Control Information (LCI) and session count
is applied to shortlist.
In this feature, the virtual APN selection is also enabled along with the dynamic UP selection. As a result,
APN is selected based on the specified criteria. The selection criteria for the Virtual APN can also be based
on location, for example, the Radio Admission Control (RAC) range.
Dynamic UP selection is done based on the configure fqdn postfix CLI command and the type of
selected APN. If the type is ECGI or CGI, then a DNS Straightforward NAPTR (S-NAPTR) query is sent
based on the cell ID. If the type is configured as tracking or routing area, then TAI or RAI is used for DNS
(S-NAPTR) query.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
151
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

To get the list of associated sx peers, UP group from the selected APN is used. The UP IPs in DNS (S-NAPTR)
response is matched with the list of sx peers in the group. The peer that is either loaded least or have least
sessions is selected from this list.

How it Works
This section describes the sequence of operation.
1. For P-GW, GGSN, or SAEGW, Fully Qualified Domain Names (FQDN) in UP, which contains
fqdn-postfix and FQDN type (EGCI/CGI or TAI/RAI) are configured at APN level.
2. During an s6b interface protocol based authorization, the fqdn-postfix value in the authorization
response is used (applicable for P-GW, GGSN, or SAEGW services only).
3. The DNS (S-NAPTR) query is sent to the DNS server.
4. The response that is received from the DNS server is matched for service x-3gpp-upf:x-sxb for
P-GW/GGSN and x-3gpp-upf:x-sxa for S-GW.
5. The matching DNS (S-NAPTR) response is processed recursively for UP IPs.
6. • If enabled, the processed IPs are shortlisted for LCI based UP selection.
• Or else, the processed IPs are shortlisted for session count based UP selection (with or without LCI).

7. If none of the UP IPs present in the response match with the associated sx peers, then, it leads to a session
creation failure.
8. For S-GW dynamic UP selection, the DNS client context must be same as sgw-service context.
9. If there is a successful DNS response for S-GW dynamic UP selection, UPs are selected from the DNS
dynamic list of UP addresses. If there is DNS failure (DNS response is empty without any UP address or
DNS time-out), the UP selection falls back to the statically configured APN profile based user-plane-groups
functionality.

Note • Pure S-GW multi-PDNs work with independent DNS based UP selection.
• S-GW relocation use cases work with independent DNS based UP selection during a handover. If
user-plane-group is configured under apn-profile, dynamic UP selection takes preference.
• After the DNS (NAPTR) query is sent, there are a few seconds of delay (equivalent to tx + rx ) to receive
the response.
• If the DNS server is not reachable, the session establishment might be delayed upto a maximum of 30
seconds before it uses the legacy method to select an UP.

The following sections describe various scenarios that are associated with the Dynamic UP Selection feature.
P-GW Dynamic UP Selection Having Virtual APN with Associated IP Pool
This section describes the sequence of operation for P-GW to dynamically select an UP having a virtual APN
with an associated IP pool.
1. As part of the create session handling, PGW-C selects a virtual APN based on the TAC range.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
152
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

2. The DNS (S-NAPTR) query is sent to the DNS server based on the configuration of the selected APN.
3. The response that is received from the DNS server is matched for service. The records with matching
service fields are considered for selection.
4. The UP IPs that are part of a configured IP pool and present in the response are matched with the associated
sx peers that are based on the UP group of the selected APN.
5. From the matching list, P-GW selects the UP that is the least loaded.

P-GW Dynamic UP Selection Having Virtual APN without Associated IP Pool

This section describes the sequence of operation for P-GW to dynamically select an UP having a virtual APN
without an associated IP pool.
1. As part of the create session handling, PGW-C selects a virtual APN based on the TAC range.
2. The DNS (S-NAPTR) query is sent to the DNS server based on the configuration of the selected APN.
3. The response that is received from the DNS server is matched for service. The records with matching
service fields are considered for selection.
4. The UP IPs that are part of any public IP pool and present in the response are matched with the associated
sx peers that are based on the UP group of the selected APN.
5. From the matching list, P-GW selects the UP that is the least loaded.

S-GW Dynamic UP Selection for Successful DNS Response

This section describes the sequence of operation for S-GW to dynamically select an UP after receiving a
successful response from the DNS server.
1. After an UE in a tracking area (or Cell ID) sends an attach request to S-GW with Dynamic ECGI, RAI-TAI
based UP selection feature is enabled and the DNS (S-NAPTR) query is sent to the DNS server.
2. S-GW receives the query response from the DNS server, which contains the list of UP IPs.
3. From the list of UP IPs, S-GW selects the UP that is the least loaded.

S-GW Dynamic UP Selection for DNS Response Time-out

This section describe the sequence of operation for S-GW to dynamically select an UP after the DNS server
time-out or the server sends a negative response.
1. The S-GW sends the DNS (S-NAPTR) query to the DNS server.
2. If there is a DNS server time-out or the server sends a negative response after the DNS (S-NAPTR) query
is sent to the DNS server, then S-GW selects an UP from the apn-profile UP group that are configured
with static IPs.
3. From the list of UP IPs, S-GW selects the UP that is the least loaded.

Call Flows
This section includes the following call flows.
DNS Query Generation and Response Handling Call Flow

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
153
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Table 4: DNS Query Generation and Response Handling Call Flow

Step Description
1 MME or S-GW sends a Create Session Request
message to the Control Plane (S-GW, P-GW, GGSN,
or SAEGW).
2 Control Plane (CP) sends an FQDN query (E-CGI or
TAI-RAI) to the DNS server.
3 CP receives the response to the FQDN query with a
list of UP IPs.
4 • If there are one or more UP IPs in the received
list, CP applies LCI to the dynamic IP list to
select an UP IP.
• Or else, CP applies session count to the static IP
list to select an UP IP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
154
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Step Description
5 • If an UP is selected, CP sends an Sx
Establishment Request message is sent to UP
(skip to step 6).
• Or else, a Create Session Reject message is sent
to MME or S-GW.

6 UP responds and sends an Sx Establishment Response

message to CP.

7 CP sends a Create Session Response message to MME

or S-GW.

DNS Query Timeout for Primary DNS Call Flow

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
155
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Table 5: DNS Query Timeout for Primary DNS Call Flow

Step Description
1 MME or S-GW sends a Create Session Request
message to the Control Plane (S-GW, P-GW, GGSN,
or SAEGW).
2 Control Plane (CP) sends an FQDN query (E-CGI or
TAI-RAI) to the primary DNS server.
3 When there is no response to the query from the
primary DNS server due to a time-out, CP retries to
send the FQDN query to the secondary DNS server.

4 CP receives the response to the FQDN query from

the secondary DNS server with a list of UP IPs.
5 • If there are one or more UP IPs in the received
list, CP applies LCI to the dynamic IP list to
select an UP IP.
• Or else, CP applies session count to the static IP
list to select an UP IP.

6 • If an UP is selected, CP sends an Sx
Establishment Request message is sent to UP
(skip to step 7).
• Or else, a Create Session Reject message is sent
to MME or S-GW.

7 UP responds and sends an Sx Establishment Response

message to CP.

8 CP sends a Create Session Response message to MME

or S-GW.

DNS Query Timeout for Primary and Secondary DNS Call Flow

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
156
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Table 6: DNS Query Timeout for Primary and Secondary DNS Call Flow

Step Description
1 MME or S-GW sends a Create Session Request
message to the Control Plane (S-GW, P-GW, GGSN,
or SAEGW).
2 Control Plane (CP) sends an FQDN query (E-CGI or
TAI-RAI) to the primary DNS server.
3 When there is no response to the query from the
primary DNS server due to a time-out, CP retries to
send the FQDN query to the secondary DNS server.

4 When there is no response to the query from the

secondary DNS server also, CP selects an UP IP from
the list of static IPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
157
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Step Description
5 • If an UP is selected, CP sends an Sx
Establishment Request message is sent to UP
(skip to step 6).
• Or else, a Create Session Reject message is sent
to MME or S-GW.

6 UP responds and sends an Sx Establishment Response

message to CP.

7 CP sends a Create Session Response message to MME

or S-GW.

Limitations
The Dynamic UP Selection feature has the following limitations:
• It's applicable for P-GW, S-GW, and SAEGW only.
• For SR and ICSR, no specific parameters are stored. If smgr is reset, the configured values are pushed
again from sessctrl.
• Any changes to the DNS Server in not considered.
• Number of IPs handled for UP are limited to six, and this list of IPs can be a combination of IPv4 and
IPv6 addresses.

Configuring the Dynamic User Plane Selection Feature

This section describes how to configure the Dynamic User Plane Selection feature.
Configuring CLI commands for P-GW or GGSN
configure
context context_name
apn apn_name
user-plane-fqdn
user-plane-fqdn fqdn_postfix_string type [E-CGI | RAI-TAI]
end
NOTES:
• user-plane-fqdn Enables use of locally configured fqdn-postfix for dynamic UP selection (DNS based).
• E-CGI Configures fqdn query type as E-CGI for UP selection
• RAI-TAI Configures fqdn query type as RAI-TAI for UP selection

Configuring CLI commands for S-GW

configure
context context_name
sgw-service sgw-service_name
user-plane-fqdn

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
158
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

user-plane-fqdn fqdn_postfix_string type [E-CGI | RAI-TAI]

end
NOTES:
• user-plane-fqdn Enables use of locally configured fqdn-postfix for dynamic UP selection (DNS based).
• E-CGI Configures fqdn query type as E-CGI for UP selection
• RAI-TAI Configures fqdn query type as RAI-TAI for UP selection

Boxer Configurations
This section describes the following boxer configurations and restrictions.
1. DNS Client must be configured and associated with P-GW and GGSN service.
2. UP FQDN must be configured in APN.
3. IP addresses of the primary and secondary DNS servers must be configured in the ISP context.
4. UP FQDN must be configured in S-GW service for S-GW dynamic UP selection.

DNS Server Configurations

This section describes the following guidelines and restrictions to configure an external DNS server:
1. DNS must be configured for NAPTR to record for ECFI/CGI/TAI/RAI, as applicable.
2. NAPTR record must have service field as "x-3gpp-upf:x-sxb" for P-GW and GGSN service and
"x-3gpp-upf:x-sxa" for S-GW.
3. NAPTR record must have flags as a to indicate that the replacement string is FQDN for A or AAAA
records.

The following CLI commands represent a sample DNS server configuration:

$ORIGIN 3gppnetwork.org.

$TTL 60 ; Put the Default

TTL in seconds here (Its 1 day currently)
3gppnetwork.org. IN SOA nsbng.3gppnetwork.org. root.3gppnetwork.org.
(

273 ; serial

7200 ; refresh (2 hours)

3600 ; retry (1 hour)

86400 ; expire (1 day)

43200 ; minimum (12 hours)

NS
nsbng.3gppnetwork.org.

ns AAAA 3001::41

;CUPS NAPTR Records Start From Here

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
159
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

;TAI NAPTR Records

tac-lb89.tac-hb67.tac.epc.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1 "a"

"x-3gpp-upf:x-sxb" ""
uplane-address1-v4.3gppnetwork.org.
tac-lb89.tac-hb67.tac.epc.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1 "a"
"x-3gpp-upf:x-sxb" ""
uplane-address1-v6.3gppnetwork.org.
tac-lb89.tac-hb67.tac.epc.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1 "a"
"x-3gpp-upf:x-sxa" ""
uplane-address1-v4.3gppnetwork.org.
tac-lb89.tac-hb67.tac.epc.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1 "a"
"x-3gpp-upf:x-sxa" ""
uplane-address1-v6.3gppnetwork.org.

;RAI NAPTR Records

rac34.lac-lb34.lac-hb12.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1 "a" "x-3gpp-upf:x-sxb"

""
uplane-address1-v4.3gppnetwork.org

rac34.lac-lb34.lac-hb12.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 2 "a" "x-3gpp-upf:x-sxb"

""
uplane-address1-v6.3gppnetwork.org.

;ECGI NAPTR Records

eci-b167.eci-b245.eci-b323.eci-b401.eci.epc.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1
"a" "x-3gpp-upf:x-sxb" ""
uplane-address1-v4.3gppnetwork.org.
eci-b167.eci-b245.eci-b323.eci-b401.eci.epc.mnc365.mcc214.3gppnetwork.org. IN NAPTR 1 1
"a" "x-3gpp-upf:x-sxb" ""
uplane-address1-v6.3gppnetwork.org.

;CGI NAPTR Records

ci-lb34.ci-hb12.ci.lac-lb34.lac-hb12.lac.ggsn.mnc365.mcc214.3gppnetwork.org. IN NAPTR
1 1
"a" "x-3gpp-upf:x-sxb" ""
uplane-address1-v4.3gppnetwork.org.
ci-lb34.ci-hb12.ci.lac-lb34.lac-hb12.lac.ggsn.mnc365.mcc214.3gppnetwork.org. IN NAPTR
1 1
"a" "x-3gpp-upf:x-sxb" ""s
uplane-address1-v6.3gppnetwork.org.

;A Records

uplane-address1-v4 100 IN
A 1.1.1.1
;uplane-address1-v4 100 IN A
1.1.1.1
uplane-address1-v4 100 IN
A 1.1.1.1
;uplane-address2-v4 100 IN
A 1.1.1.1

;AAAA Records

uplane-address1-v6 100 IN
AAAA 1::1:111

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
160
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

uplane-address1-v6 100 IN
AAAA 1111::1:111
;uplane-address2-v6 100 IN
AAAA 1111::1:111

S6b Configuration (Optional)

This section describes guidelines to configure an external S6b to support custom attribute aaa-uplane-fqdn
and to provide fqdn_post_fix_string.
AA-Answer
apn-config
uplane-fqdn

Interface
The following sections describe the format for the DNS query and response.
DNS (S-NAPTR) Query Format
This section describes the format for the DNS (S-NAPTR) query message.

Network Node Query format

S-GW-C ECGI based
eci b1<ECI byte-1>.eci b2<ECI-byte-2>. Eci b3<ECI
byte-3>
.eci
b4<ECI-byte-4>.eci.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
TAI based
tac lb<TAC low byte>.tac hb<TAC-high-byte>
.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

P-GW-C ECGI based

eci-b1<TAC-byte-1>.eci-b2<ECI-byte-2>.Eci-b3<TAC-byte-3>
.eci-b4<ECI-byte-4>.eci.epc.mnc<MNC>
.mcc<MCC>.3gppnetwork.org
TAI based
tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>
.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
161
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Network Node Query format

GGSN-C CGI based
ci-lb<CI-low-byte>.ci-hb<CI-high-byte>
.eci.lac-lb<LAC-low-byte>.lac-hb<LAC-high-byte>
.lac.ggsn.mnc<MNC>.mcc<MCC>. 3gppnetwork.org
RAI based
rac<RAC>.lac-lb<LAC-low-byte>
.lac-hb<LAC-high-byte>.lac.ggsn.mnc<MNC>
.mcc<MCC>.3gppnetwork.org

SAEGW-C (Collapsed) ECGI based

eci-b1<TAC-byte-1>.eci-b2<ECI-byte-2>
. Eci-b3<TAC-byte-3>.eci-b4<ECI-byte-4>
.eci.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
TAI based
tac-lb<TAC-low-byte>
.tac-hb<TAC-high-byte>.tac.epc.mnc
<MNC>.mcc<MCC>.3gppnetwork.org

DNS (S-NAPTR) Response Format

This section describes a sample format for DNS (S-NAPTR) response message.
Query ID : 22290

Type : Response

Question : NAPTR ?
ci-lb34.ci-hb12.ci.lac-lb34.lac-hb12.lac.ggsn.mnc365.mcc214.3gppnetwork.org.

Answer :

Name :
ci-lb34.ci-hb12.ci.lac-lb34.lac-hb12.lac.ggsn.mnc365.mcc214.3gppnetwork.org.

TTL : 60

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
162
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Type : NAPTR

Order : 1

Preference : 1

Flags : a

Service : x-3gpp-upf:x-sxb

Regexp :

Replacement : uplane-address2.3gppnetwork.org.

Name :
ci-lb34.ci-hb12.ci.lac-lb34.lac-hb12.lac.ggsn.mnc365.mcc214.3gppnetwork.org.
TTL : 60

Type : NAPTR

Order : 1

Preference : 1

Flags : a

Service : x-3gpp-upf:x-sxb

Regexp :

Replacement : uplane-address1.3gppnetwork.org.

Query ID : 44640

Type : Query

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
163
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Question : A?
uplane-address2.3gppnetwork.org.

Query ID : 55480

Type : Query

Question : A?
uplane-address1.3gppnetwork.org.

Query ID : 55480

Type :
Response

Question : A?
uplane-address1.3gppnetwork.org.

Answer :

Name : uplane-address1.3gppnetwork.org.

TTL : 100

Type : A

Address : 20.20.20.108

Query ID : 44640

Type :
Response

Question : A?
uplane-address2.3gppnetwork.org.

Answer :

Name
:
uplane-address2.3gppnetwork.org.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
164
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

TTL : 100

Type : A

Address : 1.1.1.1

Show Commands
This section describes the available show commands for the Dynamic UP Selection feature.
show apn name apn_name
This show command can be used to check the following values:
• FQDN of APN
• Type of FQDN

show sgw-service sgw-service_name

This show command can be used to check the following values:
• FQDN of APN
• Type of FQDN

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
165
 Cisco Confidential - Limited Release
Dynamic User Plane Selection
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
166
 Cisco Confidential - Limited Release

CHAPTER 22
ECS Regular Expression Support
• Feature Summary and Revision History, on page 167
• Feature Description, on page 167
• How It Works, on page 168
• Configuring Regex Rule, on page 169
• Monitoring and Troubleshooting, on page 170

Feature Summary and Revision History

Revision History

Table 7: Revision History

Revision Release
Details
First 21.20.3
introduced

Feature Description
This feature provides the Enhanced Charging Support (ECS) for regular expression (regex) rule matching.
The intent of the feature is to implement the regex engine in User Plane to enable RCM and PFD-based regex
configuration/matching. The User Plane supports the following protocols as a part of regex engine rebuild
and rule matching.
• HTTP
• URL
• URI
• HOST

• WWW
• URL

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
167
 Cisco Confidential - Limited Release
ECS Regular Expression Support
How It Works

• URI

• RTSP
• URL
• URI

How It Works
The following table lists the special characters that you can use in regex rule expressions.

Convention Description
* Zero or more characters.
+ Zero or more repeated instances of the token preceding the +.
? Zero or one character.
\character Escaped character.
\? Match on a question mark (\<ctrl-v>?)
\+ Match on a plus sign
\* Match on an asterisk
\a Alert (ASCII 7)
\b Backspace (ASCII 8)
\f Form-feed (ASCII 12)
\n New line (ASCII 10)
\r Carriage return (ASCII 13)
\t Tab (ASCII 9)
\v Vertical tab (ASCII 11)
\0 Null (ASCII 0)
\\ Back slash
Bracketed range Matching any single character from the range.
[0-9]
A leading ^ in a No match in the range. All other characters represent themselves.
range
.\x## Any ASCII character as specified in two-digit hex notation. For example, \x5A yields
a ‘Z’.

Following are the two ways to configure the regex rule:

• Regex rule configuration via RCM:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
168
 Cisco Confidential - Limited Release
ECS Regular Expression Support
Configuring Regex Rule

• Regex rule configuration via PFD Push:

Configuring Regex Rule

Following are the two ways to configure the Regex Rule.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
169
 Cisco Confidential - Limited Release
ECS Regular Expression Support
Configuring Regex Rule via RCM

Configuring Regex Rule via RCM

Configure the regex rule via RCM through User Plane CLI instance or directly on User Plane via CLI.
configure
require rcm-configmgr
end

Configuring Regex Rule via PFD Push

Configure the regex rule on Control Plane through the User Plane via PFD push.
configure
push config-to-up all
end

Sample Configuration
Following are the sample configuration for configuring the Regex Rule.
configure
active-charging service <service_name>
ruledef <ruledef_name>
http url regex <regex_url>
rtsp uri regex <regex_uri>
www url regex <regex_url>
end

Note • For RCM - Execute the regex rule configuration through the User Plane CLI instance.
• For PFD - Execute the regex rule configuration through the Control Plane and execute the PFD push.

Monitoring and Troubleshooting

This section provides information on CLI commands that are available for monitoring and troubleshooting
for Regex support in User Plane.

Show Commands and Outputs

This section provides information about show CLI commands that are available in support of Regex support
in User Plane.
• show user-plane-service regex status: Use this command to display the engine status for SessMgr
instance.
• show user-plane-service regex statistics memory: Use this command to display the memory stats for
SessMgr instance.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
170
 Cisco Confidential - Limited Release
ECS Regular Expression Support
Show Commands and Outputs

• show user-plane-service regex statistics memory summary: Use this command to display the combined
memory summary for the SessMgr.
• show user-plane-service regex statistics ruledef: Use this command to display the regex ruledef stats
for the SessMgr.
• show user-plane-service regex statistics ruledef summary:
Use this command to display the combined regex ruledef stats summary for the SessMgr.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
171
 Cisco Confidential - Limited Release
ECS Regular Expression Support
Show Commands and Outputs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
172
 Cisco Confidential - Limited Release

CHAPTER 23
End Marker Packets
• Revision History, on page 173
• Feature Description, on page 173

Revision History
Revision Details Release

First introduced. 21.10 (9/18/2018)

Feature Description
In case of eNodeB relocation during handover procedure without SGW-U change, the SGW-C indicates the
SGW-U to switch the S1 path(s) by sending a Sx session modification request message with the new F-TEID-u
of eNodeB. In addition, provides an indication to the SGW-U to send the End Marker Packet(s) on the old
path. On receiving this indication, the SGW-U constructs End Marker Packet(s) and sends it for each S1
GTP-U tunnel toward the source eNodeB, after sending the last PDU on the old path.
End Marker packet is sent per GTP-U TEID during above scenarios.
The Control Plane requests the User Plane to construct and send End Marker packets by sending a Session
Modification Request including FAR(s) with the new downstream F-TEID, and with the SNDEM (Send End
Marker Packets) flag set.

Information Element P Condition/Comment

PFCPSMReq-Flags C SNDEM (Send End Marker Packets): This IE shall be present if the
CP function modifies the F-TEID of the downstream node in the
Outer Header Creation IE and the CP function requests the UP
function to construct and send GTP-U End Marker messages toward
the old F-TEID of the downstream node.

Limitation
Handoffs in P-GW is not supported for sending End Marker. This behavior is similar to non-CUPS.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
173
 Cisco Confidential - Limited Release
End Marker Packets
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
174
 Cisco Confidential - Limited Release

CHAPTER 24
Enterprise Onboarding in CUPS
• Feature Revision History, on page 175
• Feature Description, on page 175
• How it Works, on page 177
• Enterprise Onboarding in CUPS OAM Support, on page 188

Feature Revision History

Table 8: Revision History

Revision Details Release

With this release, the entry order for CP and UP in CUPSinfo.txt 21.20.10
file is modified.

With this release, a new command option is introduced to display 21.20.9

the version of the IOB tool.

The feature is fully qualified in this release. 21.20.4

First introduced. 21.20.3

The feature is not fully qualified in this release.

Feature Description
In CUPS architecture, User Planes (SAEGW-U) are grouped into a logical concept called User Plane Group
(UP Group) and controlled by a Control Plane (CP) node. An APN is associated with a UP Group, and the
UP for IP pool is selected based on least-used User Plane.
During configuration of new APNs and IP pools, the operator must decide on a UP Group to be used. The
information required to decide the UP Group is not exposed by the system and the process is tedious and error
prone. Also, the number of contexts, APNs, VRFs, and IP pools are reduced both on CP and UP in CUPS
architecture as compared with ASR 5500. This also limits the addition of new APNs and IP Pools to the right
context and UP Group.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
175
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Operational Use Case

The Intelligent Onboarding (IOB) tool automates the procedure of choosing the right UP Group and SGi
context for the new APN to be added. The tool gathers current resources that are configured (number of UP
Groups, UPs per group, existing contexts, APNs, and IP pools) in the CUPS system. It then determines if the
system can absorb the new configuration and determines the UP Group that can support without breaching
the system limits. In line with this, the new configuration is applied by the tool.

Operational Use Case

The Enterprise requires an operator to add, modify, and/or delete a user with information based on APN and
IP pools. The tool generates and applies the required configuration to add, modify, or delete an APN in the
CUPS environment.
The following operations can be performed:
• Enterprise Addition: A new APN is added with required number of IPv4/IPv6 pools.
• Enterprise Modification: IP pools can be added/deleted for an existing APN.
• Enterprise Deletion: An APN will be deleted.

Architecture
On ASR 5500, Enterprise addition consists of adding a new APN. For CUPS, along with the APN configuration,
we must include the correct UP Group and SGi context configuration.
The IOB tool takes inputs from the Provisioning tool, chooses the best suited UP Group and SGi context for
the APN, and configures the CP and UP. The IOB tool also allows modification of the APN configuration
(adding/deleting the IP pools) and Deletion of an APN.

Installation
The IOB tool is shipped as Linux executable. All dependencies, like Pexpect and connection management
library, are packaged into the standalone .exe file.
The tool is shipped with StarOS images and signed with the same keys that are used for StarOS VPC-SI image.
The executable tool requires the following environment:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
176
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
How it Works

• RedHat Enterprise Linux 7.6 (or CentOS equivalent) 64-bit installation

• OpenSSL version 1.0.2.k-fips
• The following shared libraries are installed under /lib64 (these are typically present in a standard RHEL
or CentOS installation):
• libdl.so.2
• libz.so.1
• libc.so.6
• ld-linux-x86-64.so.2

• Read, write, execute permissions for /tmp directory. While executing, the tool creates a temporary directory
under /tmp, extracts sections of the executable to this temporary directory and executes the sections.
• Sufficient disk space for the tool and the log files (current usage is approximately 10 MB)
• IP connectivity to CPs and UPs on which onboarding is to be done. Password-based SSH is used for
connections.

How it Works
The IOB tool is a standalone application that leverages StarOS CLIs to collect the system level resources,
read the configurations, check the errors, SRP information, and so on. The input parameters to the IOB tool
include addressing and login credentials for CPs and UPs, details of the operation (add/modify/delete), and
the specific configuration to be applied. Since the contexts to apply the configuration to may not be known
beforehand, the input configuration specifies a dummy context as a placeholder. The IOB tool substitutes that
dummy context with the specific context that is chosen prior to applying the configuration.
Also, as part of Enterprise Onboarding solution, a new CLI command is introduced, and an existing CLI
command is modified. For details, see Enterprise Onboarding in CUPS OA&M Support section.
The IOB tool goes through the following steps:
• Pre-processing: This is performed to ensure that the system is in stable state to proceed with the
onboarding operation. On successful validation, the IOB tool collects the current resource usage
information from the system.
• Context and UP Group Selection: The IOB tool applies the onboarding algorithm to select a context
and UP Group to onboard the APN.
• Configuration: Based on the operation to be performed, an algorithm is applied using the data collected
in the Pre-processing step. The configuration is then applied on CP and UP. For any failure scenario, the
IOB tool attempts to roll back to the previous configuration.
• Post-processing: Post configuration checks are performed to validate the system for any errors. For any
failure scenario, the IOB tool attempts to roll back to the previous configuration.
• Logging: The entire operation is logged. The logging mechanism captures the output of the operation,
history of the operation, Warnings/Error messages, and any other information that helps in debugging.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
177
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Pre-Processing

Pre-Processing
Pre-processing step helps in understanding the status of the CUPS system where the onboarding operation is
being performed. In the pre-processing stage, following checks are performed irrespective of the operation:
• Verify if all CP and UP management IPs are reachable:
• Ping Active/Standby management IPs of all the CPs.
• Ping Active/Standby management IPs of all the UPs.

• Collect the resources information (APN, IP Pools, VRF, and Context) based on the output of:
• show ip user-plane verbose
• show cups-resources session summary

• Add Operation:
• On Control Plane node, following checks are performed:
• Verifies that the VRF, APN, and IP pool to be onboarded is not configured in the system.
• Verifies that there is no configuration difference between Active/Standby CPs using show srp
info.

• After context and UP Group selection, on User Plane node, the following pre-processing checks
are performed on all the UPs of the selected UP Group:
• Verifies that the VRF to be onboarded doesn't exist in the system. If it exists, then the
pre-processing fails and onboarding is aborted.
• Verifies that there is no configuration difference between Active/Standby UPs using show srp
info.
• Verifies if SGi context is mapped in the UP Groups.

• Modify Operation:
• On Control Plane node, following checks are performed:
• Verifies that the VRF to be modified exists in the system.
• Verifies that the APN to be modified exists in the system.
• Verifies that the IP pools, deleted as part of modify operation, exists in the system. Any IP
pool that is added as part of modify operation, doesn't exist in the system.
• Verifies that there is no configuration difference between Active/Standby CPs using show srp
info.

• Delete Operation:
• On Control Plane node, following checks are performed:
• Verifies that the VRF to be deleted exists in the system.
• Verifies that the APN to be deleted exists in the system.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
178
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
CP and UP Configuration

• Verifies that there is no configuration difference between Active/Standby CPs using show srp
info.

• On User Plane node, following checks are performed:

• Verifies that the VRF to be deleted exists in the system.
• Verifies that there is no configuration difference between Active/Standby UPs using show srp
info.

CP and UP Configuration
On successful pre-processing, the tool performs the Add/Modify/Delete operation as per the input and applies
the configuration on CP and UP. For ICSR setups, the configuration is applied on both Active and Standby
CP and UPs.
• Add operation: The algorithm chooses the right SGi context and UP group for the APN to be added.
• On Control Plane node, following steps are performed:
• The chosen SGi context and the UP Group are added to the APN configuration, which goes as
input to the tool.
• The updated configuration is then applied to the CP node.

• On User Plane node:

• The IOB tool replaces the dummy SGi context with chosen context, and applies the resulting
configuration to all the UPs in the chosen UP Group.
• Applies VRF configurations to all the UPs in the UP Group.

• For any failure scenario, the IOB tool attempts to roll back to the previous configuration.

• Modify Operation: Configuration is modified to add or delete the IP pools.

• On Control Plane node:
• For the given APN configuration, IP pool configuration is modified to add/delete the IP pools.
If any IP pools are deleted, then prior to deletion, the tool:
• Busyouts the pool.
• Clears existing subscribers for that pool with a pace-out interval of 600 seconds.

• For any failure scenario, the IOB tool attempts to roll back to the previous configuration.

• Delete Operation: Deletes the APN.

• On Control Plane node:
• IP pools and VRFs, associated with the APN, are deleted.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
179
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Post-Processing

Prior to deleting any APN, the IOB tool verifies if any user is attached to the given APN. If
any user exists, it exits from the tool and displays an error message "Please clear the subscribers
then run the DELETE_ENTERPRISE else it will delete the APN".
• APN configuration is deleted.

• On User Plane node, VRF configurations are deleted.

The IOB tool doesn't rollback to the previous configuration on a failure. It, however, tries to delete
as much of the relevant configuration as possible to minimize the amount of manual clean-up
required.

Post-Processing
After the configurations are pushed to CP and UP, checks are performed to validate configuration changes.
• Add Operation:
• On Control Plane node, following checks are performed:
• Verifies configured VRF with show ip vrf vrf_name: To verify if the VRF configuration is
applied in the CUPS system.
• Verifies that the chosen context is shown with show configuration apn apn_name: To verify
if the context has been associated with the APN that is added.
• Verifies that the chosen UP Group is shown under show configuration apn apn_name: To
verify if the UP Group has been associated with the APN that is added.
• Saves configuration using save configuration file_path / file_name: After successful addition
of new enterprise, checks if the respective configuration files are stored in the given path as
mentioned in "CUPSinfo.txt" file.
• Synchronize configuration on CPs with filesystem synchronize: After successful addition of
new enterprise, verifies the file synchronization.
• Verifies that there is no configuration difference between CPs using show srp info: SRP
validation in ICSR setup: After successful addition of new enterprise, the IOB tool checks for
SRP validation with "Primary" and "secondary" status, "Last Peer Configuration Error",
"Connection State", along with "Number of Sessmgrs".

• On User Plane node, following checks are performed:

• Verifies configured VRF with show ip vrf vrf_name: To verify the VRF configuration applied
in the CUPS system.
• Verifies Route Distinguisher using show ip vrf vrf_name: To verify the Route Distinguisher
configuration applied in the CUPS system.
• Save configuration using save configuration file_path / file_name.
• Invoking SRP validation using srp validate-configuration: Verifies that there is no
configuration difference between UPs using show srp info: SRP validation in ICSR setup.

• For any failure scenario, the IOB tool attempts to roll back to the previous configuration.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
180
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Add Operation

• Modify Operation:
• On Control Plane node, following checks are performed:
• Verifies that the modified changes are applied to the CUPS system.
• Verifies that the changes to IP pool are reflected in the system
• Saves configuration using save configuration file_path / file_name.
• Invoking SRP validation using srp validate-configuration: Verifies that there is no
configuration difference between UPs using show srp info: SRP validation in ICSR setup

• For any failure scenario, the IOB tool attempts to roll back to the previous configuration.

• Delete Operation:
• On Control Plane node, following checks are performed:
• Verifies if the APN configuration is deleted from the CUPS system.
• Verifies if the VRF configuration is deleted from the CUPS system.
• Saves configuration using save configuration file_path / file_name.
• Invoking SRP validation using srp validate-configuration: Verifies that there is no
configuration difference between UPs using show srp info: SRP validation in ICSR setup

• On User Plane node, following checks are performed:

• Verifies if the VRF configuration is deleted from the CUPS system.
• Saves configuration using save configuration file_path / file_name.
• Invoking SRP validation using srp validate-configuration: Verifies that there is no
configuration difference between UPs using show srp info: SRP validation in ICSR setup.

Add Operation
The Add operation configures a new APN for the enterprise customer. The algorithm chooses the right SGi
context and UP Group, and maps them to the APN by taking the system parameters into consideration.
Algorithm Logic:
• Check for System Limits (done against CP limits mentioned in System Limits, on page 187).
• Rank UP Groups based on number of APNs configured with low numbers on top.
• Sort the SGi contexts based on the number of VRFs configured in ascending order.
• Exclude VIP UP Groups and Contexts from the list.
• Pick a UP Group from top of the list (least-used):
• Get a Context that is mapped to UP Group (if no Contexts are mapped, pick from the sorted list).
• Check the number of VRFs, IPv4, IPv6 pools, and total pool size.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
181
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Modify Operation

• Choose the Context if checks fall within thresholds; else, repeat for next Context.
• Pick suitable Context within limits; if none found, exit algorithm.
• For this UP Group, iterate through UPs and check total IP pool limits.
• If successful, choose the UP Group and Context.

• Iterate through all UP Groups.

• At each step, while checking against the thresholds, print error messages.
• Prepare the configuration with chosen Context and UP Group and apply.

Modify Operation
Modify operation allows the onboarded Enterprise customer to increase/decrease the subscribers by Adding
more IP pools or deleting the existing IP pools.

Delete Operation
Delete operation removes a previously onboarded Enterprise. During this operation, the IOB tool cleans up
the IP pools, VRFs, and APNs that are used for the Enterprise.
To delete an Enterprise, the following procedure must be followed as there may be active subscribers on the
system:
• Busyout the IP Pools: This is performed to block the new subscribers. Invoke IOB tool and perform the
Busyout operation using the MODIFY operation.
• Clear Subscribers: The Provisioning tool clears the active subscribers.
• Delete the Enterprise: Invoke the IOB tool and perform the enterprise removal using the DELETE
operation.

Password Encryption
The IOB tool expects passwords in the "CUPSInfo.txt" input file to be RSA encrypted and converted to base64
format. Encryption is done using OpenSSL (currently, version 1.0.2.k is supported) commands and RSA
public key. The IOB tool must be provided the path to the corresponding RSA private key so that it can decrypt
the passwords. The decrypted passwords are stored only in the IOB tool's RAM. The detailed steps for
encryption and decryption are described below:
1. Verify that the OpenSSL with the correct version is installed on the target machine:
• "openssl version" should indicate that the version is 1.0.2.k-fips.

2. Generate RSA private and public key pair:

a. RSA private key:

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:4096

Where:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
182
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Password Encryption

• "private_key.pem" represents the generated private key file in PEM format. This is used for
decryption and has to be stored securely.
• 4096 is the key length in bits. Either 2048 or 4096 can be used. Multiple passwords may need
to be encrypted and so, 4096 is recommended. Generally, the larger the key size, the larger the
size of data it can encrypt. However, it also takes longer to encrypt/decrypt.

b. RSA public key:

openssl rsa -pubout -in private_key.pem -out public_key.pem

Where:
• "private_key.pem" is the private key generated in Step (a).
• "public_key.pem" is the file that contains the corresponding public key.

3. For each password that needs to be encrypted, do the following:

a. Type the password in plaintext in a text file using an editor. Don't hit enter at the end of the line. It
should have just the password in a single line. In this example, the file is named as "pp1".
b. Execute:

openssl pkeyutl -encrypt -inkey public_key.pem -pubin -in pp1 -out encrypted_pp1

Where:
• "public_key.pem" is the public key generated in Step 2b.
• "pp1" is the file containing the single password in plaintext.
• "encrypted_pp1" contains the password in encrypted form.

Delete "pp1" created in Step 3a to avoid accidental exposure.

c. "encrypted_pp1" contains the key in raw binary form. Convert it to base64 as follows:

base64 encrypted_pp1

d. The above command (Step 3c) will output the base64 encoded encrypted password to the terminal.
Copy and paste this into the "CUPSinfo.txt" file that contains the credentials supplied to the IOB tool.
While copying, make sure to remove any line breaks or spaces. The entire password should be a single
line.
e. "encrypted_pp1" can be deleted at this point.

Note Step 3 must be performed for each password, one at a time, using the same public key/private key pair for all
the passwords.

After "CUPSinfo.txt" file is updated with all the encrypted base64 passwords, the IOB tool is ready to be run.
When running the script, specify an additional parameter: -k absolute path to private_key.pem created in Step
2a>.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
183
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Onboarding Application – Usage and Input Parameters

Onboarding Application – Usage and Input Parameters

The application is compiled to create a standalone .exe. The application can be run on a RedHat Enterprise
Linux machine.
The Onboarding Application can be run with below syntax:
./intelligent_onboarding -o <OP_Type_Parameter_File> -i <CUPS_Info_File> -k
<Path_to_Pvt_Key_file> [ -l <Path_to_store_logfiles> ] [ -p ] [ --context_selection_from_cp
] [ -v ]

Options:
• -o: [Mandatory] Provide the input parameter file specific to the operation being invoked.
After successful onboarding, the IOB tool deletes the file.
• -i: [Mandatory] This option is used for "CUPSinfo.txt" file which has the details of CUPS system.
• -k: [Mandatory] Absolute path to the private key file. The tool uses this to decrypt the previously encrypted
passwords. This private key file must correspond to the public key that is used to encrypt the passwords.
• -p: [Optional] When included, few pre-audit and post-audit checks are bypassed to reduce the time taken
for Add/Modify/Delete operation.
• -l: [Optional] Provide absolute path to store the logs.
When this keyword is not specified, the log files are created in the directory from which the IOB tool is
invoked.
• --context_selection_from_cp: [Optional] When specified, the tool bases its context selection solely on
the list of contexts available on the CP. The tool assumes that the selected context is also available on
the UPs and does not validate this. This is an optimization. The default behavior is to examine contexts
configured on CP and UP and select from contexts common to both.
• -v: [Optional] Displays the version of the IOB executable.
If IOB tool is executed without the -v option, the version is displayed that is similar to:
###############################################################
# #
# WELCOME TO ENTERPRISE ONBOARDING #
# Version 21.20.9.private #
# #
###############################################################

NOTE: The version is displayed in the log file and terminal output as well.

CUPSinfo.txt
Onboarding application must know the system-level details to carry out the onboarding operations. The
"CUPSinfo.txt" file has the IP addresses for CP and UP nodes and configurable threshold values.
"Skip_UPGroup" and "Skip_Context" refers to the UP Groups and contexts that must not be considered for
onboarding algorithm. For example, VIP groups and contexts that cannot be used for other enterprises. The
file specifies a path where the configuration must be saved. The passwords in this file must be specified in
RSA encrypted, base 64 format.
In 21.20.9 and earlier releases, the entry order of CP and UP inputs were:
//Control_Plane:
Host,Node,Primary_IP,Secondary-IP,Login,Password,Primary_config_path,Secondary_config_path

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
184
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Sample CUPSinfo.txt File

//User_Plane:
Host,Node,Primary_IP,Secondary-IP,Login,Password,Sx-IP-Address,Primary_config_path,Secondary_config_path

In 21.20.10 and later releases, the entry order of CP and UP inputs are:
//Control_Plane:
Host,Node,Primary_IP,Secondary-IP,Primary_config_path,Secondary_config_path,Login,Password
//User_Plane:
Host,Node,Primary_IP,Secondary-IP,Sx-IP-Address,Primary_config_path,Secondary_config_path,Login,Password

Sample CUPSinfo.txt File

For 21.20.9 and earlier releases:
//Threshold for Warning, input as percentage values

CPContext_threshold = {vrf_threshold:80, ipv4_threshold:80, ipv6_threshold:80}

CPSystem_threshold = {vrf_threshold:80, total_pool_threshold:80, apn_threshold:80}
UPContext_threshold = {vrf_threshold:80, ipv4_threshold:80, ipv6_threshold:80}
UPSystem_threshold = {vrf_threshold:80, apn_threshold:80, total_pool_threshold:80}
UPBudgeted_Sessions_threshold = {budgeted_threshold:80}

SKIP_UPGroup =
SKIP_Context =

//Control_Plane:
Host,Node,Primary_IP,Secondary-IP,Login,Password,Primary_config_path,Secondary_config_path
cups_di_cp1,Control_Plane,192.0.0.2,192.0.0.2,<login_id>,<password>,
/flash/192.0.0.2-cups-vpp-saegw-global-control-plane.cfg,
/flash/192.0.0.2-cups-vpp-saegw-global-control-plane.cfg

//User_Plane:
Host,Node,Primary_IP,Secondary-IP,Login,Password,Sx-IP-Address,Primary_config_path,Secondary_config_path
cups_di_up0,User_Plane,192.0.0.1,192.0.0.1,<login_id>,<password>,
192.1.1.1,/flash/192.0.0.1-cups-vpp-saegw-global-user-plane-.cfg,
/flash/192.0.0.1-cups-vpp-saegw-global-user-plane.cfg
cups_di_up1,User_Plane,192.1.0.1,192.1.0.1,<login_id>,<password>,
192.0.0.3,/flash/192.1.0.1-cups-vpp-saegw-global-user-plane.cfg,
/flash/192.1.0.1-cups-vpp-saegw-global-user-plane.cfg

In 21.20.10 and later releases:

//Threshold for Warning, input as percentage values

CPContext_threshold = {vrf_threshold:98, ipv4_threshold:98,ipv6_threshold:98}

CPSystem_threshold = {vrf_threshold:98, total_pool_threshold:98, apn_threshold:98}
UPContext_threshold = {vrf_threshold:98, ipv4_threshold:98, ipv6_threshold:98}
UPSystem_threshold = {vrf_threshold:98, apn_threshold:98, total_pool_threshold:98}
UPBudgeted_Sessions_threshold = {budgeted_threshold:80}

SKIP_UPGroup =
SKIP_Context =

//Control_Plane: Host,Node,Primary_IP,Secondary-IP,Primary_config_path,
Secondary_config_path,Login,Password
cups_di_cp1,Control_Plane,192.0.0.2,192.0.0.2,/flash/192.0.0.2-CP01.cfg,
/flash/192.0.0.2-CP02.cfg,<login_id>,<password>
//User_Plane: Host,Node,Primary_IP,Secondary-IP,Sx-IP-Address,Primary_config_path,
Secondary_config_path,Login,Password
cups_si_up1,User_Plane,192.1.0.1,192.1.0.1,192.0.0.3,/flash/192.1.0.1-UP01.cfg,
/flash/192.1.0.1-UP02.cfg,<login_id>,<password>

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
185
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
ADD_ENTERPRISE_INPUT_PARAMETERS.txt

ADD_ENTERPRISE_INPUT_PARAMETERS.txt
This file provides the configuration information when an APN is added. It provides the IP pool information
and VRF information. The context provided is dummy and the actual context is determined as part of the
algorithm. The IP pools doesn't support chunks.
NOTE: In case of onboarding a virtual APN, the tool expects the virtual APN configuration to be specified
in the "CP_APN_Config" section of the file before any real APN configuration.

Sample ADD_ENTERPRISE_INPUT_PARAMETERS.txt

OpType = "ADD_ENTERPRISE"

CP_APN_Config = '''Config
context APN
apn starent.com
ip address pool name starent_ipv4_pool_group_01
ipv6 address prefix-pool starent_ipv6_pool_group_01
exit
exit
exit'''

// script will replace the dummy-SGI context with the chosen context
CP_SGi_Context = '''Config
context dummy-SGi
ip vrf MPN00001
ip pool starent_ip_pool_v4_001 194.0.0.1 255.0.0.2 private 0 no-chunk-pool group-name
starent_ipv4_pool_group_01 vrf MPN00001
ip pool starent_ip_pool_v4_002 194.0.0.4 255.0.0.2 private 0 no-chunk-pool group-name
starent_ipv4_pool_group_01 vrf MPN00001

ipv6 pool starent_ip_pool_v6_001 prefix 2001:1:1::/48 private 0 no-chunk-pool group-name

starent_ipv6_pool_group_01 vrf MPN00001

exit
exit'''

// UP VRF config
// script will replace the dummy-SGI context with the chosen context
UP_VRF_Config= '''config
context dummy-SGI
ip vrf MPN00001
ip maximum-routes 100
exit
router bgp 65101
ip vrf MPN00001
route-distinguisher 65101 11100001
route-target both 65101 11100001
exit
address-family ipv4 vrf MPN00001
redistribute connected
exit
address-family ipv6 vrf MPN00001
redistribute connected
exit
exit
exit
exit'''

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
186
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
MODIFY_ENTERPRISE_INPUT_PARAMETERS.txt

MODIFY_ENTERPRISE_INPUT_PARAMETERS.txt
This file provides the IP pools that must be added to or deleted from an existing enterprise. The context name
is determined based on the pool name.

Sample MODIFY_ENTERPRISE_INPUT_PARAMETERS.txt

OpType = "MODIFY_ENTERPRISE"
CP_APN_Config = '''Config
context APN
apn cisco.com
exit
exit
exit'''
CP_SGi_Context = '''Config
context dummy-SGi
no ip pool cisco_ip_pool_v4_002 194.0.0.1 255.0.0.2 private 0 no-chunk-pool group-name
starent_ipv4_pool_group_01 vrf MPN00001
ip pool starent_ip_pool_v4_003 194.0.0.4 255.0.0.2 private 0 no-chunk-pool group-name
starent_ipv4_pool_group_01 vrf MPN00001
exit
exit'''

DELETE_ENTERPRISE_INPUT_PARAMETERS.txt
This input file must contain APN, SGi context, and VRF details when the request is to remove the enterprise.

Sample DELETE_ENTERPRISE_INPUT_PARAMETERS.txt

OpType= "DELETE_ENTERPRISE"

CP_APN_Config = '''config
context APN
no apn cisco.com
exit
exit'''

// script will replace the dummy-SGI context with the chosen context
CP_SGi_Context = '''config
context dummy-SGi
no ip vrf MPN00001

exit
exit'''

// UP VRF config
// script will replace the dummy-SGI context with the chosen context
UP_VRF_Config = '''config
router bgp 65101
no ip vrf MPN00001
exit
exit'''

System Limits
The following table depicts the maximum limits on ASR 5500 and CUPS.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
187
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Enterprise Onboarding in CUPS OAM Support

Table 9: System Limits

Parameter ASR 5500 Control Plane User Plane

VRF Limit 300 per context • 300 per context: Derived 205 VRF (with default
from the output of show ip routes): Derived from the
2048 per chassis
user-plane verbose CLI output of show ip
command. user-plane verbose CLI
command. Must calculate
• 1500 per chassis: Derived per UP.
from the output of show ip
user-plane verbose CLI
command that is added
across all contexts.

IP Pool Limit IPv4: 2000 per context IPv4: 2000 per context - Derived Total of 600 IP pools per
from the output of show ip context per UP group:
IPv6: 256 IPv6 per
user-plane verbose CLI
context • Total of 600 IP pools
command.
can consist a
5000 per chassis
IPv6: 256 IPv6 per context maximum of 256 IPv6
(combined IPv4 and
IP pools.
IPv6) 3400 per chassis (combined
IPv4 and IPv6) - Derived from • Total of 600 IP pools
the output of show ip can consist a
user-plane verbose CLI maximum of 600 IPv4
command. IP pools.

Derived from the output of

show ip user-plane
verbose CLI command.
Must calculate the value
from the output (Max 600
IPv4 pools, Max 256 IPv6
pools).

APN Limit 2048 Total of 1500 for the system: 205 per UP: Derived from
Derived from the output of show the output of show
cups-resource session cups-resource session
summary CLI command. summary CLI command.
Must calculate per UP.

Note The IOB tool allows only one APN to be onboarded at a time. The CUPSinfo.txt file is considered as the
primary UP information. If any UP Groups are added in the system, but are not present in the file, then they
are excluded from onboarding.

Enterprise Onboarding in CUPS OAM Support

This section describes operations, administration, and maintenance information for this feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
188
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Show Commands

Show Commands
show cups-resource session summary
This CLI command is introduced in support of the Enterprise Onboarding in CUPS solution. The output of
this CLI command displays system-level resources on CP.
NOTES:
• Group Name Column displayed in output is the name of UP Group.
• Sx-IP shows the IP address of UP configured under the UP Group.
• APN, Active-Sessions, and LCI details are for the UP Group.

show ip user-plane verbose

The output of this CLI command is enhanced to display Total Pool Kernel Routes and Max Pool Kernel Routes
fields. The dynamic IPv4 and IPv6 pool count is replaced with total IPv4 and IPv6 pool count. The output of
this CLI command displays the context and UP Group it belongs to, and also adds information on number of
IP pools and VRFs for that UP.

Error Codes
The following list of error codes is available in support of Enterprise Onboarding in CUPS feature.

Error Code Description

1001 Indicates that the parsing of Input files has failed.
1002 Indicates that the parsing of Input_parameters file has failed.
1003 Indicates that the parsing of CUPSinfo file has failed.
1004 Indicates the inability to decrypt the passwords.
1005 Indicates that OpType is not present in input parameters.
1006 Indicates that the required configurations are not available in Input_parameters file
for a given OpType.
1101 Indicates that the system pre-processing has failed.
1102 Indicates that the CPs pre-audit has failed for a given OpType.
1103 Indicates that the UPs pre-audit has failed for <UP_name>.
1301 Indicates that the CONTEXT and UPGROUP are not available for selection.
1401 Indicates the inability to find <context_name> and <group_name> from the CUPS
system.
1501 Indicates the inability to get <context_name> from the output of show apn CLI
command.
1601 Indicates that the configurations have failed for <control/user plane name>
<connection state>.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
189
 Cisco Confidential - Limited Release
Enterprise Onboarding in CUPS
Error Codes

Error Code Description

1602 Indicates that the rollback configurations have failed for <control/user plane name>
.
1701 Indicates that the CP post-audit has failed for <control plane name> <connection
state>.
1702 Indicates that the UP post-audit has failed for <user plane name> <connection state>.
1703 Indicates that the Sx re-association has failed.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
190
 Cisco Confidential - Limited Release

CHAPTER 25
Event-based CDRs for CUPS
This chapter includes the following topics:
• Revision History, on page 191
• Event-based CDRs for CUPS, on page 191
• Feature Description, on page 191
• How It Works, on page 192
• Standards Compliance, on page 194
• Monitoring and Troubleshooting, on page 194

Revision History
Revision Details Release

The Event-based CDRs for CUPS is fully qualified in this release. 21.9 (5/31/2018)

First introduced. 21.9 (5/4/2018)

The Event-based CDRs for CUPS is not fully qualified in this release.

Event-based CDRs for CUPS

This chapter includes the following topics:

Feature Description
The CUPS architecture now supports Even-based Call Data Record (CDR) generation to account subscriber
data usage. The EPC network, which consists of the User-Plane and Control-Plane as separate nodes, requires
interaction between these entities to provide data usage accounting.
Generation of a CDR is an integral functionality of the Control-Plane. The Control-Plane interacts with the
User-Plane to receive usage data such as: Uplink bytes, Downlink bytes and so on, to generate a CDR. These
CDRs are generated based on Event Triggers. The event triggers can be either from the Access side of the
Control-Plane or PCRF generated. The usage data acquired from these events from the User-Plane, is updated
in the CDR.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
191
 Cisco Confidential - Limited Release
Event-based CDRs for CUPS
How It Works

The following functionalities are supported in this feature:

• Exchange of Packet Flow Control Plane (PFCP) Session Modification Request and PFCP Session
Modification Response messages.
• Reporting usage data from the User-Plane to the Control-Plane based on a configured Tariff-Time.

Note The scope of this feature is restricted only to P-GW and SAE-GW.

How It Works
The usage data report of a subscriber is retrieved from the User-Plane using the following mechanisms:
• Pull mechanism: The Control-Plane queries the User-Plane for the usage data report. The PFCP Session
Modification Request/ PFCP Session Modification Response messages are used in this mechanism.
• Push mechanism: Here, the User-Plane sends the usage data report to the Control-Plane. The Tariff-Time
configuration, which works with the existing Time/Volume-based push mechanism, is implemented.
The PFCP Session Report Request/Session Report Response messages are used in this mechanism.

Fetching the Usage Report

In the CUPS architecture, because the User-Plane is a separate node, the Control-Plane node communicates
with the User-Plane node using the PFCP protocol over the Sx interface to retrieve the usage data report of a
subscriber.
The Control-Plane node sends the PFCP Session Modification request, containing the URRs for which the
usage data report is reported. The User-Plane node responds with the PFCP Session Modification Response
providing the usage data report for the requested URRs.
The following figure depicts the interaction between Control-Plane and User-Plane:

The following IEs are supported as part of the Sx Session Modification exchange messages:
• Query URR: This IE is present when the Control-Plane function requests immediate usage report(s) to
the User-Plane function. Several IEs within the same IE type may be present to represent a list of URRs
for which an immediate report is requested.
• Usage Report: This IE is present if the Query URR IE was present in the PFCP Session Modification
Request and the traffic usage measurements for that URR are available at the User-Plane function. Several
IEs within the same IE type may be present to represent a list of Usage Reports.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
192
 Cisco Confidential - Limited Release
Event-based CDRs for CUPS
Tariff Time

Tariff Time
Tariff-Time configuration is already supported by the Non-CUPS architecture. For CUPS, the Control-Plane
uses the existing configuration. During a call set-up, PFCP Session Establishment Request carries the tariff
time in the Monitoring Time IE, which is applicable to SDF URRs only. Bearer Level URR does not have
this IE.
The Monitoring Time IE contains the configured time at which the usage data report of a subscriber is sent
to the Control-Plane. Once the configured monitoring time expires the usage data report is sent, and sequentially,
the time is automatically moved ahead by 24 hours indicating the time at which the next usage data report
will be sent.

Note Before the next expiry of monitoring timer, usage data is reported continuously through the Time/Volume
Threshold, if configured, or through an explicit request by the Control-Plane using the PFCP Session
Modification Request (Query URR).

On the User-Plane, when the monitoring time expires for a URR, the Usage Report IE is sent to the
Control-Plane. Sometimes, the monitoring time could expire for multiple subscribers at the same time. To
avoid flooding of usage reports towards the Control-Plane, the User-Plane instead of reporting, piggybacks
the usage data in the next outgoing message (PFCP Session Report Request or PFCP Session Modification
Response) carrying the usage report.
The following IEs are supported as part of the Create URR IE within PFCP Session Modification Request:
• Monitoring Time: This IE contains the time at which the User-Plane function re-applies the volume or
time threshold.
• Subsequent Volume Threshold: This IE may be present if the Monitoring Time IE is present and
volume-based measurement is used. When present, it indicates the traffic volume value after which the
User-Plane function reports the network resources usage to the Control-Plane function for the respective
URR, for the period after the Monitoring Time.
• Subsequent Time Threshold: This IE may be present if the Monitoring Time IE is present and time-based
measurement is used. When present, it indicates the traffic time value after which the User-Plane function
reports the network resources usage to the Control-Plane function for the respective URR, for the period
after the Monitoring Time.

Note In the non-CUPS architecture, P-GW supports four tariff-time instances in the Tariff-Time configuration.
However, in CUPS only one tariff-time instance is supported.

Event Trigger
In this feature, an event trigger results in generation of either a partial CDR or a permanent CDR. In case of
a partial event, only the CDR bucket is updated, but the actual CDR is not generated. But, in a permanent
event trigger, a complete CDR is generated.
The following event triggers are supported in this feature:
• ULI Change (Partial event)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
193
 Cisco Confidential - Limited Release
Event-based CDRs for CUPS
Standards Compliance

• Time Zone Change (Permanent event)

• Default Bearer QoS Change
• APN-AMBR Change

Note The GTPP trigger egcdr max-losdv is not supported in this release.

Standards Compliance
The Event-based CDRs for CUPS is based on the following standard(s):
• 3GPP TS 29.244: LTE; Interface between the Control Plane and the User Plane of EPC Nodes (3GPP
TS 29.244 version 14.0.0 Release 14)

Monitoring and Troubleshooting

This section provides information on the show commands available to support Event-based CDRs for CUPS.

Show Commands and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature:

show active-charging subscribers full callid call_id urr-info

On executing the above command the following new fields are displayed:
• Next Monitoring Time
• Subsequent Time Threshold
• Subsequent Volume Threshold

show subscribers user-plane-only callid call_id urr full all

On executing the above command the following new fields are displayed:
• Next Monitoring Time
• Subsequent Time Threshold
• Subsequent Volume Threshold

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
194
 Cisco Confidential - Limited Release

CHAPTER 26
Event Data Records in CUPS
• Revision History, on page 195
• Feature Description, on page 196
• How It Works, on page 196
• Configuring Event Data Records in CUPS, on page 199
• Monitoring and Troubleshooting, on page 200

Revision History
Revision Details Release

With this release, the following EDR attributes are added for TCP: 21.21.0
• SYN and SYN-ACK packet
• SYN-ACK and ACK packet

Support for the following field in the EDR is added in this release. 21.20.x
• P2P Duration
• Rating group
• Radius NAS-Identifier
• 3GPP Charging-id
• SN-Parent Protocol-id

With this release, the following EDR attributes are added: 21.15.1
• tcp-state
• tcp-prev-state

First introduced. 21.15.M0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
195
 Cisco Confidential - Limited Release
Event Data Records in CUPS
Feature Description

Feature Description
Generation of Event Data Records (EDR) is supported in the CUPS architecture.
These EDRs are generated on termination of a flow. Detailed information for every flow is generated after
the flow termination.
Following are the EDR fields that gets populated in the event of EDR generation due to the flow end, transaction
complete, and so on or whenever the necessary conditions are met.
• P2P Duration
• Rating group
• RADIUS NAS Identifier
• 3GPP Charging-id
• SN-Parent Protocol-id

When the data traffic with TCP starts for a subscriber attached to LTE network. Need to calculate and record
time difference between control packets of TCP flow in EDR. Need to record the difference between following
packets:
• SYN and SYN-ACK packet
• SYN-ACK and ACK packet

TCP Fast Open

TCP Fast Open (TFO) is an extension to speed up the opening of successive TCP connections between two
endpoints. It works by using a TFO cookie (a TCP option), which is a cryptographic cookie stored on the
client and set upon the initial connection with the server. When the client later reconnects, it sends the initial
SYN packet along with the TFO cookie data to authenticate itself. If successful, the server may start sending
data to the client even before the reception of the final ACK packet of the three-way handshake. Due to this
RTT between SYN-ACK and ACK is calculated based on difference between SYN-ACK packet and first
uplink ACK packet.

How It Works
EDRs are generated from UP on flow termination. During call setup and call modification, all call-specific
attributes required for EDR generation is sent from CP to UP as part of the Subscriber Params IE within the
Sx Establishment/Modification request messages.
On flow termination, the charging counters are fetched from VPP. All configured call-level attributes in the
EDR format configuration along with the charging / volume counter attributes is sent to the CDRMOD proclet.
This proclet writes these records to a file/disk, which is transferred to a configured external server.

Transaction Complete EDR

Transaction complete EDRs are generated for HTTP EDRs when a HTTP transaction is complete. On
completion, the charging counter are fetched from VPP. All configured call-level attributes in the EDR format

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
196
 Cisco Confidential - Limited Release
Event Data Records in CUPS
How It Works

configuration along with the charging / volume counter attributes is sent to the CDRMOD proclet. This proclet
writes these records to a file/disk, which is transferred to a configured external server.
The following list of EDR attributes are supported:
• attribute sn-start-time
• attribute sn-end-time
• attribute sn-start-time format MM/DD/YYYY-HH:MM:SS:sss
• attribute sn-end-time format MM/DD/YYYY-HH:MM:SS:sss
• attribute radius-calling-station-id
• attribute radius-called-station-id
• rule-variable bearer 3gpp imsi
• rule-variable bearer 3gpp imei
• rule-variable bearer 3gpp rat-type
• rule-variable bearer 3gpp user-location-information
• rule-variable ip subscriber-ip-address
• rule-variable ip dst-address
• attribute sn-ruledef-name
• attribute sn-subscriber-port
• attribute sn-server-port
• attribute sn-app-protocol
• attribute sn-volume-amt ip bytes uplink
• attribute sn-volume-amt ip bytes downlink
• attribute sn-flow-start-time format seconds
• attribute sn-flow-end-time format seconds
• attribute sn-volume-amt ip pkts uplink
• attribute sn-volume-amt ip pkts downlink
• attribute sn-direction
• rule-variable traffic-type
• rule-variable p2p protocol
• rule-variable p2p app-identifier tls-cname
• rule-variable p2p app-identifier tls-sni
• rule-variable p2p app-identifier quic-sni
• rule-variable bearer 3gpp sgsn-address

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
197
 Cisco Confidential - Limited Release
Event Data Records in CUPS
How It Works

• attribute sn-rulebase
• attribute sn-charging-action
• rule-variable flow tethered-ip-ttl
• rule-variable flow ttl
• rule-variable flow ip-control-param
• rule-variable bearer qci
• rule-variable tcp flag
• rule-variable ip server-ip-address
• attribute sn-flow-id
• attribute sn-closure-reason
• attribute sn-duration
• rule-variable ip src-address
• rule-variable ip protocol
• attribute sn-charge-volume ip bytes uplink
• attribute sn-charge-volume ip bytes downlink
• tcp-state
• tcp-prev-state

The following HTTP EDR attributes are supported:

• rule-variable http url length 2000
• rule-variable http request method
• rule-variable http content type
• rule-variable http user-agent length 255
• rule-variable http reply code
• rule-variable http referer
• rule-variable http host
• rule-variable http cookie
• rule-variable http header-length
• attribute transaction-uplink-bytes
• attribute transaction-downlink-bytes

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
198
 Cisco Confidential - Limited Release
Event Data Records in CUPS
Limitations

Limitations
The Event Data Record feature in CUPS has the following limitations:
• EDR will be generated only for flow end condition – idle timeout, hagr, normal flow termination &
during end of session.
• Charging-Action based EDR configuration is not supported.
• Reporting EDRs are not supported.

Configuring Event Data Records in CUPS

Configuration on CP to Push EDRs to UP
Use the following configuration to push EDRs from CP to UP using PFD mechanism.

Note The CLI commands used in this configuration are part of the existing non-CUPS architecture.

active-charging service service_name

rulebase rulebase_name
flow end-condition { timeout | normal-end-signaling | session-end |
hagr } charging-edr charging_edr_format_name
edr transaction-complete http charging-edr charging_edr_format_name
exit
edr-format format_name
attribute attribute_name
end
NOTES:
• flow end-condition: This command allows you to configure the end condition of the session flows related
to a user session and triggers EDR generation.
• timeout: Creates an EDR with the specified EDR format whenever a flow ends due to a timeout condition.
• normal-end-signaling: Creates an EDR with the specified EDR format whenever flow end is signaled
normally.
• session-end: Creates an EDR with the specified EDR format whenever a subscriber session ends. By
this option session manager creates an EDR with the specified format name for every flow that has had
any activity since last EDR was created for the flow on session end.
• charging-edr charging_edr_format_name: Specifies the charging EDR format.
• hagr: Creates an EDR with the specified EDR format whenever a flow is terminated due to Inter-chassis
Session Recovery action.
• http: Specifies HTTP protocol related configuration.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
199
 Cisco Confidential - Limited Release
Event Data Records in CUPS
Configuration to Enable EDR Module on UP

Configuration to Enable EDR Module on UP

Use the following configuration to enable EDR module on UP

Note The CLI commands used in this configuration are part of the existing non-CUPS architecture.

configure
context context_name
edr-module active-charging-service
end

Configuring Additional TCP Fields

Prior to using the following CLI commands to configure additional TCP fields in the EDR, ensure that all the
other EDR configurations are present.

Note For CUPS setup, once configuration is present on CP side, push those changes on UP using push config-to-up
all command from CP.

configure
active-charging service service_name
edr-format edr_format_name
[ no ] rule-variable tcp syn_synack_rtt priority 3
[ no ] rule-variable tcp syn_synack_ack_rtt priority 4
end

Monitoring and Troubleshooting

show user-plane-service statistics rulebase name rulebase_name
The following fields are displayed in support of this feature:
• Rulebase Name
• EDRs
• Charge Volume
• Uplink Pkts
• Uplink Bytes
• Downlink Pkts
• Downlink Bytes

• Charging EDRs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
200
 Cisco Confidential - Limited Release
Event Data Records in CUPS
show active-charging rulebase statistics real-time

• Total Charging EDRs generated

• EDRs generated for handoff
• EDRs generated for timeout
• EDRs generated for normal-end-signaling
• EDRs generated for session end
• EDRs generated for rule match
• EDRs generated for hagr
• EDRs generated for flow-end content-filtering
• EDRs generated for flow-end url-blacklisting
• EDRs generated for content-filtering
• EDRs generated for url-blacklisting
• EDRs generated for any-error packets
• EDRs generated for firewall deny rule match
• EDRs generated for transaction completion
• EDRs generated for voip call end
• EDRs generated for dcca failure handling
• EDRs generated for TCP optimization on
• EDRs generated for tethering signature change
• EDRs generated for interim interval
• Total Flow-Overflow EDRs
• Total zero-byte EDRs suppressed

• Total Rulebases

show active-charging rulebase statistics real-time

The following fields are displayed in support of this feature:
• Rulebase Name
• Charging EDRs
• Total Charging EDRs generated
• EDRs generated for handoff
• EDRs generated for timeout
• EDRs generated for normal-end-signaling

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
201
 Cisco Confidential - Limited Release
Event Data Records in CUPS
show active-charging edr-format all

• EDRs generated for session end

• EDRs generated for rule match
• EDRs generated for hagr
• EDRs generated for flow-end content-filtering
• EDRs generated for flow-end url-blacklisting
• EDRs generated for content-filtering
• EDRs generated for url-blacklisting
• EDRs generated for any-error packets
• EDRs generated for firewall deny rule match
• EDRs generated for transaction completion
• EDRs generated for voip call end
• EDRs generated for dcca failure handling
• EDRs generated for TCP optimization on
• EDRs generated for tethering signature change
• EDRs generated for interim interval
• EDRs generated for audio-end Sessions
• EDRs generated for video-end Sessions
• EDRs generated for voipout-end Sessions
• Total Flow-Overflow EDRs
• Total zero-byte EDRs suppressed

show active-charging edr-format all

The following fields are displayed in support of Additional TCP Fields in EDR feature:
• Service Name
• EDR Format Name
• rule-variable tcp syn-synack-rtt priority 3
• rule-variable tcp synack-ack-rtt priority 4

Bulks Statistics
The following bulk statistic(s) are added in the ECS schema to support Event Data Records in CUPS:
• edrs-generated: Indicated the total number of EDRs generated.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
202
 Cisco Confidential - Limited Release

CHAPTER 27
Error Indication and GTPU Path Failure Detection
• Revision History, on page 203
• Feature Description, on page 203
• How It Works, on page 204
• Configuring Error Indication and GTPU Path Failure on Control Plane, on page 210

Revision History
Revision Details Release

In this release, added the page-ue configuration support and configuration 21.16.1
limitations.

First introduced. 21.15.1

Feature Description
The User Plane (UP) function notifies an Error Indication message for a GTPU peer to the sender when a
GTP-PDU is received with a TEID that does not exist. This ensures that there are no stale sessions or bearers
and maintains consistency in the network.
Error Indication and GTPU Path Failure between CP and UP nodes are supported over SxA, SxB and SxAB.
For the neighbor nodes, it is supported over the S1u/S5u interfaces.
Behavior variations of local-purge or signal-peer for error indication and GTPU path failure are considered
in this implementation.
• When Error Indication is received, the UP communicates the TEID and GTPU-peer information with
the CP to ensure deletion or modification of the GTPU-peer.
• On receiving GTPU packet with non-existing TEID, the UP generates and sends Error Indication with
TEID and GTPU peer entries.
• The deletion of a session or a bearer is decided based on the path failure detection at CP or UP.
• GTPU path failure is detected using GTPU echo messages between UP nodes, and between the UP and
CP nodes.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
203
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
How It Works

As per 3GPP TS 29.244, the following is implemented in this feature:

• The PFCP Session Report Request is sent over the Sxa and Sxb interface by the UP function to report
information related to an PFCP session to the CP function.
• The PFCP Session Report Response is sent over the Sxa and Sxb interface by the CP function to the UP
function as a response to the PFCP Session Report Request.
• Error Indication Report IE must be present if the Report Type indicates an Error Indication Report.
• Remote F-TEID is sent in the Error Indication Report to identify the remote F-TEID of the GTP-U bearer
for which an Error Indication has been received at the UP function.
• The PFCP Node Report Request is sent over the Sxa and Sxb interface by the UP function to report
information to the CP function that is not specific to an PFCP session.
• The PFCP Node Report Response is sent over the Sxa, Sxb; Sxc and N4 interface by the CP function to
the UP function as a response to the PFCP Node Report Request.
• UPPath Failure Report will be present if the Node Report Type indicates a User Plane Path Failure Report.
• Remote GTP-U Peer includes the IP address of the remote GTP-U peer towards which a UP path failure
has been detected.

How It Works
Error Indication Support
Error Indication Handling at CP
CP on receiving a PFCP Session Report Request triggered by Error Indication received on UP from a
neighboring UP, responds with PFCP Session Report Response and sends a PFCP Session Modification
Request towards UP to delete PDR, a FAR for dedicated bearer identified for removal or a PFCP Session
Deletion Request to delete the session.
• The session or bearer will be locally purged on PGW-C on reception of PFCP Session Deletion Response
or PFCP Session Modification Response from UP respectively.
• For SAEGW-C, signaling over EGTP is based on local purge and page-ue configuration for S1u.
• For SGW-C, signaling over EGTP on CP is based on local purge and page-ue configuration for S1u
and local-purge and signal peer on S5u.

Error Indication Handling on UP

UP on receiving Error Indication initiates a PFCP Session Report Request with Error Indication Report that
includes remote FTEID containing TEID and GTPU Peer address.
• For PGW-U, Error Indication messages is sent or received over S5u.
• For SAEGW-U, Error Indication message is sent or received over S1u.
• For SGW-U, Error Indication message is sent and received over S1u and S5u.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
204
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
Error Indication Generation on UP

Error Indication Generation on UP

UP generates Error Indication with TEID and GTPU Peer Address towards a peer when a data packet is
received with TEID for which a session or bearer does not exist.

Error Indication Call Flows

P-GW Default Bearer Error Indication Handling

The following call flow illustrates P-GW default bearer error indication handling with local purge.

P-GW Dedicated Bearer Error Indication Handling

The following call flow illustrates P-GW dedicated bearer error indication handling with local purge.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
205
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
Error Indication Call Flows

S-GW Default Bearer Indication Handling

The following call flow illustrates S-GW dedicated bearer error indication handling with S5u local purge.

S-GW Dedicated Bearer Indication Handling

The following call flow illustrates S-GW dedicated bearer error indication handling with S1u local purge.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
206
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
Error Indication Call Flows

S-GW Dedicated Bearer Indication Handling

The following call flow illustrates S-GW dedicated bearer error indication handling with S5u local purge.

S-GW Dedicated Bearer Indication Handling

The following call flow illustrates S-GW dedicated bearer error indication handling with S5u signal peer.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
207
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
GTPU Path Failure Support

GTPU Path Failure Support

GTPU Path Failure Support at CP
GTPU Echo Requests is initiated and sent periodically as per the configured interval on CP. GTPU Echo
Response is sent for the GTPU Echo Request received from UP over the GTPU tunnel.
If Response is not received for the GTPU Echo Request, CP retries Echo Requests based on configured
retransmission timeout and maximum retries. When retries are exhausted, CP initiates PFCP Session Deletion
Request to delete the PFCP session.
On receiving the PFCP Node Report Request from UP, CP will send PFCP Node Report Response and initiate
PFCP Session Deletion Request towards UP. Billing records will be generated when usage reports are received
in PFCP Session Deletion Response.
The following call flow illustrates GTPU Path Failure handling at CP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
208
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
GTPU Path Failure Support at UP

GTPU Path Failure Support at UP

GTPU Echo Requests is initiated and sent periodically as per the configured interval on UP. GTPU Echo
Response is sent for the GTPU Echo Request received from CP over GTPU tunnel.
If Response is not received for the GTPU Echo Request, UP retries Echo Requests based on configured
retransmission timeout and maximum retries. When retries are exhausted, UP shall initiate PFCP Node
Report Request including (Node ID, Node Report Type, User Plane Path Failure Report including Remote
GTP-U Peer).
If UP receives PFCP Node Report Response and PFCP Session Deletion Request to delete the session, it
responds to the deletion request with usage reports.
The following call flow illustrates GTPU Path Failure support at UP

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
209
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
Limitations

Limitations
In this release, the Error Indication and GTPU Path failure feature has the following limitations:
• UP on receiving following messages/packets with Extension Headers will respond with Supported
Extension Headers Notification indicating neighboring UPs that extension headers are not supported.
• Error Indication
• GTPU Echo Requests
• GTPU Echo Response
• GTP-PDU

Configuring Error Indication and GTPU Path Failure on Control

Plane
Configuring Error Indication on CP
Use following commands to control the behavior of CP towards EGTP peers based on GTPU error indication
received on a GTPU interface (s1u/s5u).
configure
context context_name
sgw-service service_name

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
210
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
Configuring GTPU Path Failure on CP

gtpu-error-ind { s1u { local-purge | page-ue }| s5u { local-purge

| signal-peer } }
end
NOTES:
• gtpu-error-ind: Configures the actions to be taken upon receiving a GTP-U error indication from P-GW.
• s1u: Specifies the action to take when a GTP-U error indication is received from P-GW over the S1u
interface.
• s5u: Specifies the action to take when a GTP-U error indication is received from P-GW over the S5u
interface.
• local-purge: The S-GW clears the affected bearer (or PDN if error-indication is received on default
bearer) locally without informing peer.
• page-ue: The S-GW moves the complete UE state to S1-Idle and starts paging for this UE.
• signal-peer: Clears the affected bearers or PDNs and initiates control signals towards the peer MME
and P-GW.

Note The extension-header source-udp-port CLI option is not supported for GTP-U service on User Plane.

Configuring GTPU Path Failure on CP

Use following commands to control the behavior of CP towards EGTP peers based on GTPU path failure
detected on GTPU interface (s1u/s5u).
configure
context context_name
sgw-service service_name
path-failure { s1u | s5u }{ local-purge | signal-peer }
end
NOTES:
• path-failure: Configures the action to take upon the occurrence of a path failure between the S-GW and
the MME or P-GW.
• s1u: Specifies the action to take when a GTP-U error indication is received from P-GW over the S1u
interface.
• s5u: Specifies the action to take when a GTP-U error indication is received from P-GW over the S5u
interface.
• local-purge: The S-GW clears the affected bearer (or PDN if error-indication is received on default
bearer) locally without informing peer.
• signal-peer: Clears the affected bearers or PDNs and initiates control signals towards the peer MME
and P-GW.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
211
 Cisco Confidential - Limited Release
Error Indication and GTPU Path Failure Detection
Limitations

Limitations
The following CLI options are not supported in this release:
• In GTP-U service on UP: extension-header source-udp-port
• In SG-W service on CP:
gtpu-error-ind s4u
gtpu-error-ind s11u
gtpu-error-ind s12
path-failure s4u
path-failure s11u
path-failure s12

When Sx Session Modification Response for Error Indication or GTP-U Path Failure is pending from User
Plane and Collapsed to Pure-P Handover request is received, Modify Bearer Request for Handover is processed
once Sx Session Modification Response which was delayed is received. Following configuration is
recommended for working of above case for handover to be successfully completed.
configure
context egresscontext_name
ims-auth-service service_name
policy-control
max-outstanding-ccr-u 2
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
212
 Cisco Confidential - Limited Release

CHAPTER 28
Firewall Support in CUPS
• Revision History, on page 213
• Feature Description, on page 213
• Configuring the Default Firewall Feature, on page 214
• Monitoring and Troubleshooting, on page 216
• Show CLIs for CUPS, on page 217
• SNMP Traps, on page 217
• Reassembly Behavior Change, on page 218

Revision History
Table 10: Revision History

Revision Release
Details
First 21.22.x
introduced

Feature Description
Subscriber Firewall feature on CUPS architecture allows you to configure Stateless and Stateful packet
inspection and packet filtering to protect the subscribers from malicious attacks. The firewall configuration
allows the system to inspect each packet of the subscriber data session. It also evaluates the security threat
and applies the policies configured on uplink and downlink traffic.

Note The subscriber firewall implementation in CUPS is like the firewall implementation in non-CUPS architecture.
For more details on the subscriber firewall in non-CUPS, see the PSF Administration Guide.

Overview
Firewall feature includes the support for the following:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
213
 Cisco Confidential - Limited Release
Firewall Support in CUPS
Configuring the Default Firewall Feature

• DoS attack
• DDoS attack
• Packet Filtering
• Stateless & stateful packet inspection
• Application level gateways
• SNMP thresholding and logging

Configuring the Default Firewall Feature

Following is the default configuration for the FW policy.
configure
active-charging service service_name
fw-and-nat policy policy_name
end
Along with the preceding service configuration, Following is the default CLI behavior of various FW related
CLI within the service.
Dos-Protection:
Source-Route : Disabled
Win-Nuke : Disabled
Mime-Flood : Disabled
FTP-Bounce : Disabled
IP-Unaligned-Timestamp : Disabled
Seq-Number-Prediction : Disabled
TCP-Window-Containment : Disabled
Teardrop : Disabled
UDP Flooding : Disabled
ICMP Flooding : Disabled
SYN Flooding : Disabled
Port Scan : Disabled
IPv6 Extension Headers Limit : Disabled
IPv6 Hop By Hop Options : Disabled
Hop By Hop Router Alert Option : Disabled
Hop By Hop Jumbo Payload Option : Disabled
Invalid Hop By Hop Options : Disabled
Unknown Hop By Hop Options : Disabled
IPv6 Destination Options : Disabled
Invalid Destination Options : Disabled
Unknown Destination Options : Disabled
IPv6 Nested Fragmentation : Disabled

Max-Packet-Size:
ICMP : 65535
Non-ICMP : 65535
Flooding:
ICMP limit : 1000
UDP limit : 1000
TCP-SYN limit : 1000
Sampling Interval : 1

TCP-SYN Flood Intercept:

Mode : None
Max-Attempts : 5

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
214
 Cisco Confidential - Limited Release
Firewall Support in CUPS
Enabling Firewall for IPv4 and IPv6

Retrans-timeout : 60
Watch-timeout : 30
Mime-Flood Params:
HTTP Header-Limit : 16
HTTP Max-Header-Field-Size : 4096

No Firewall Ruledef Match Action:

Uplink Action : permit
Downlink Action : deny

TCP RST Message Threshold : Disabled

ICMP Dest-Unreachable Threshold : Disabled
Action upon receiving TCP SYN packet with ECN/CWR Flag set : Permit
Action upon receiving a malformed packet : Deny
Action upon IP Reassembly Failure : Deny
Action upon receiving an IP packet with invalid Options : Permit
Action upon receiving a TCP packet with invalid Options : Permit
Action upon receiving an ICMP packet with invalid Checksum: Deny
Action upon receiving a TCP packet with invalid Checksum: Deny
Action upon receiving an UDP packet with invalid Checksum: Deny
Action upon receiving an ICMP echo packet with id zero : Permit
TCP Stateful Checks : Enabled
First Packet Non-SYN Action: Drop
ICMP Stateful Checks: Enabled
TCP Partial Connection Timeout: 30

Enabling Firewall for IPv4 and IPv6

Following is the configuration to enable the firewall for IPv4 and IPv6:
configure
active-charging service service_name
fw-and-nat policy policy_name
firewall policy ipv4-and-ipv6
end

Configuration Support for Subscriber Firewall

The Control Plane pushes the required configuration for the subscriber firewall to the User Plane through
PFD management. Firewall configurations are available under active charging configuration.
• Access-Rule-Defs
• Firewall-Nat Policy

Firewall feature configuration supports activation of firewall feature using rulebase, APN-based, and/or
subscriber-based activation.
This section details the different aspect of configuration for the subscriber firewall in CUPS.
• Config delete command deletes the configuration immediately. It doesn’t wait for bulk config timer as
the said config is removed from the SCT and it’s deleted from all Sessmgrs immediately.
• Addition/deletion/Modification of firewall configuration from CP to UP propagates using CLI command
“push config-to-up all”.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
215
 Cisco Confidential - Limited Release
Firewall Support in CUPS
Monitoring and Troubleshooting

Monitoring and Troubleshooting

Following is the show command output for the default Firewall feature on Control Plane.

show config active-charging service name acs verbose

fw-and-nat policy SFW_NAT_TEST
no firewall dos-protection source-router
no firewall dos-protection winnuke
no firewall dos-protection mime-flood
no firewall dos-protection ftp-bounce
no firewall dos-protection ip-unaligned-timestamp
no firewall dos-protection tcp-window-containment
no firewall dos-protection teardrop
no firewall dos-protection flooding udp
no firewall dos-protection flooding icmp
no firewall dos-protection flooding tcp-syn
no firewall dos-protection port-scan
no firewall dos-protection ipv6-extension-hdrs
no firewall dos-protection ipv6-hop-by-hop
no firewall dos-protection ipv6-hop-by-hop router-alert
no firewall dos-protection ipv6-hop-by-hop jumbo-payload
no firewall dos-protection ipv6-hop-by-hop invalid-options
no firewall dos-protection ipv6-hop-by-hop unknown-options
no firewall dos-protection ipv6-dst-options
no firewall dos-protection ipv6-dst-options invalid-options
no firewall dos-protection ipv6-dst-options unknown-options
no firewall dos-protection ipv6-frag-hdr nested-fragmentation
no firewall dos-protection ip-sweep tcp-syn
no firewall dos-protection ip-sweep udp
no firewall dos-protection ip-sweep icmp
firewall max-ip-packet-size 65535 protocol icmp
firewall max-ip-packet-size 65535 protocol non-icmp
firewall flooding protocol icmp packet limit 1000
firewall flooding protocol udp packet limit 1000
firewall flooding protocol tcp-syn packet limit 1000
firewall flooding sampling-interval 1
firewall tcp-syn-flood-intercept mode none
firewall tcp-syn-flood-intercept watch-timeout 30
firewall mime-flood http-headers-limit 16
firewall mime-flood max-http-header-field-size 4096
no firewall icmp-destination-unreachable-message-threshold
access-rule no-ruledef-matches uplink action permit
access-rule no-ruledef-matches downlink action deny
firewall tcp-idle-timeout-action reset
no firewall tcp-reset-message-threshold
firewall tcp-syn-with-ecn-cwr permit
firewall malformed-packets drop
firewall ip-reassembly-failure drop
no firewall validate-ip-options
firewall tcp-options-error permit
firewall icmp-echo-id-zero permit
firewall icmp-checksum-error drop
firewall tcp-checksum-error drop
firewall udp-checksum-error drop
firewall tcp-fsm first-packet-non-syn drop
firewall icmp-fsm
firewall policy ipv4-and-ipv6
firewall tcp-partial-connection-timeout 30
no nat policy
no nat binding-record

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
216
 Cisco Confidential - Limited Release
Firewall Support in CUPS
Show CLIs for CUPS

no nat pkts-drop edr-format

no nat pkts-drop timeout
default nat suppress-aaa-update
nat private-ip-flow-timeout 180
nat check-point-info basic limit-flows 100
nat check-point-info sip-alg
nat check-point-info h323-alg
nat max-chunk-per-realm single-ip
#exit

Show CLIs for CUPS

Following are the show CLIs for the CUPS:
For User Plane:
• show subscribers user-plane-only full all
• show subscribers user-plane-only flows
• show user-plane-service inline-services firewall statistics verbose
• show user-plane-service statistics rulebase all
• show alarm outstanding all
• show alarm outstanding all verbose
• show alarm statistics
• show user-plane-service statistics rulebase name <rulebasename>

For Control Plane:

• show active-charging fw-and-nat policy all
• show active-charging fw-and-nat policy name "fw_nat_policy_name"
• show active-charging firewall track-list attacking-servers
• show active-charging ruledef name

SNMP Traps
Following are the SNMP traps in support of this feature for CUPS, Use the respective trap CLIs on the User
Plane to enable the trap.
• Dos-Attacks: When the number of DoS attacks exceed the set threshold value, the SNMP trap is generated,
and the trap is cleared when the number falls below the threshold value within the time interval configured.
• Drop-Packets: When the number of packets dropped exceeds the threshold value, the SNMP trap is
generated, the trap is cleared when the number falls below the threshold value within the time interval
configured.
• Deny-Rule: When the number of Deny Rules exceeds the threshold value, the SNMP trap is generated,
the trap is cleared when the number falls below the threshold value within the time interval configured.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
217
 Cisco Confidential - Limited Release
Firewall Support in CUPS
Reassembly Behavior Change

• No-Rule: When the number of No Rules exceeds the threshold value, the SNMP trap is generated, the
trap is cleared when the number falls below the threshold value within the time interval configured.

Reassembly Behavior Change

Following are the details about the CUPS reassembly, which are different from the non-CUPS architecture:
• In non-CUPS architecture, with the default FW configuration, fragments are buffered up to 64K bytes.
Beyond 64K, all buffered and subsequent fragments are dropped. In non-CUPS architecture, this 64K
limit was configurable from 30000 -> 65535. In CUPS, it is possible to reassemble the packet size of
maximum 9k in a maximum of six fragments.
• Following are the four CLIs from the non-CUPS architecture that are deprecated in the CUPS:
• firewall dos-protection teardrop
• firewall dos-protection ipv6-frag-hdr nested-fragmentation
• firewall max-ip-packet-size <30000-65535> protocol non-icmp
• o firewall max-ip-packet-size <30000-65535>protocol icmp

• The following is a single CLI that covers teardrop attack, nested fragmentation, and general
ip-reassembly-failure. Max-ip-packet size support is limited to six fragments (~9000 bytes).
• o Firewall ip-reassembly-failure

• Following are the counters in firewall statistics, that gets incremented for all the attacks related to
reassembly.
• Packets Dropped due to IPv4 Reassembly Failure
• Downlink Dropped Bytes on IPv4 Reassembly Failure
• Uplink Dropped Bytes on IPv4 Reassembly Failure
• Packets Dropped due to IPv6 Reassembly Failure
• Downlink Dropped Bytes on IPv6 Reassembly Failure
• Uplink Dropped Bytes on IPv6 Reassembly Failure

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
218
 Cisco Confidential - Limited Release

CHAPTER 29
Gx-alias Enhancement
• Revision History, on page 219
• Feature Description, on page 219
• How it Works, on page 219

Revision History
Revision Details Release

First introduced. 21.22.2

Feature Description
The Gx-alias enhancement feature is a method of installing multiple sets of predefined rules with a single
Gx-alias rule name. This rule name comes from PCRF and is transparent to PCEF, where PCRF either activates
or deactivates by naming each rule.
This feature is applicable for rules that are installed only on default bearer. To successfully install large number
of rules, you must configure no policy-control update-default-bearer CLI command under the ACS
configuration mode or the no tft-notify-ue-def-bearer CLI command under the ACS Rulebase configuration
mode to implement it on a per-rulebase level. All the ruledefs, defined under the Gx-alias Group of Ruledef
(GoR), must also be defined under the rulebase for it to get applied to the session.

How it Works
The CP expands the GoR for Gx-alias, allocates the PDR IDs to these installed rules, and carries the information
in a vendor-specific TLV. As part of this information, the Gx-alias name with Start and End of the PDR IDs
are sent to the UP. The UP, after receiving this new TLV, expands the Gx-alias into ruledefs and maps the
corresponding PDR IDs in a sequence which is governed by the configuration on UP.
The functionality/behavior of the Gx-alias Enhancement feature includes:
• Before and after the configuration updates, contents of the Gx-alias GoR are exactly the same, and in
the same order, on both CP and UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
219
 Cisco Confidential - Limited Release
Gx-alias Enhancement
Call Flow

• Addition of a new ruledef in a Gx-alias GoR is applied only to new sessions. Only deletion of a ruledef
from a Gx-alias GoR is handled in existing session.
• Predefined rules functionality at UP has no impact when Gx-alias is mapped to the ruledefs. That is,
URR-IDs/charging is transparent to Gx-alias being used.

NOTE:
• Maximum limit of GoRs that can be configured: 64
• Maximum number of rules allowed per GoR: 512
• Maximum rules allowed per default bearer: 2048

IE Format of Gx-alias
The following table provides the IE Format and encoding information of the Gx-alias feature.

Bits
Octets 8 7 6 5 4 3 2 1
1 to 2 Type = 246 (decimal)
3 to 4 Length n [Min=7, Max=69 {5+ACSCTRL_GRP_OF_RDEFS_NAMELEN (64)}]
5 Flags (Add/Delete GoR Rules)
For example: 1 for Add, 0 for Delete rules in GoR

6 to 7 Start PDR ID
8 to 9 End PDR ID
10 to n+4 Gx-alias GoR name (min size=2, max size=64)

PFCP_IE_GX_ALIAS: IE to communicate a Gx-alias GoR name, Start and End PDR IDs, and also the
operation to perform from Control Plane to User Plane during Sx Session Establishment/Modification Request
message.

Call Flow
This section describes the Gx-alias enhancement call flow.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
220
 Cisco Confidential - Limited Release
Gx-alias Enhancement
Call Flow

Step Description
1 S-GW sends a Create Sessions Request with S5/S8 SGW-U FEID to SAEGW-PGW-C.
2 SAEGW performs Gx communication CCR-I with PCRF.
During a Pure-P call for CUPS SAEGW, the SAEGW-PGW-C does the following:
• After Gx interaction, performs Gx communication (CCR-I and CCA-I) with PCRF.
• Performs User Plane selection based on User Plane profile configured with IP pool
(APN associated IP pool).
• Establishes GTP-U session required for RA/RS for IPv6/IPv4v6 PDN.
• Performs Sxb interaction with the selected User Plane.

3 PCRF performs Gx communication CCA-I with SAEGW.

Sx Establishment Request session contains the following information:
• GoR/GoR Action/FAR/URR information for uplinks and downlink data path:
dynamic/predefined/static rules.
• Also, Control Plane requests User Plane to allocate F-TEID for P-GW ingress, PDR
S5/S8 PGW-U F-TEID. In Gx-alias GoRs, ruledefs must be within the same order for
Control Plane and User Plane that are part of Day-0 configuration. The newly
configured rules apply only to new sessions that are Cisco-specific Control Plane and
User Plane node pairs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
221
 Cisco Confidential - Limited Release
Gx-alias Enhancement
Limitation

Step Description
4 SAEGW establishes a Sx Sessions Establishment Request (Sxb) with the User Plane.
The new IE format for Gx-alias, PFCP_IE_GX_ALIAS does the following actions:
• Communicate a Gx-alias GoR (Group-of-Ruledef) name
• Start/End PDR IDs
• Perform operations from the Control Plane to the User Plane during the Sx Session
Establishment/Modification Request message.

5 The User Plane provides "P-GW ingress PDR S5/S8-U PGW F-TIED" information as part
of Sx Session Establishment Response and establishes a Sx Sessions Establishment Response
(Sxb) with SAEGW-PGW-C.
6 On receipt of the Sx Session Establishment Response, SAEGW-PGW-C sends Create
Session Response towards S-GW with "S5/S8-U PGW F-TEID".

Limitation
Following are the known limitations of the feature:
• IE-handling is applicable only between Cisco-supported Control Plane-User Plane nodes. All ruledefs
configured in Gx-alias GoR are bound only to the default bearer.
• To avoid exceeding the recovery time, only eight GoRs are recovered during session recovery. The
maximum recommended limit of GoRs to be configured is eight (8).
• With 2048 rules, you may see an impact on scaling of sessions. The maximum recommended rules per
default bearer is 1000.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
222
 Cisco Confidential - Limited Release

CHAPTER 30
Gy Multiple MSCC and FUI-Redirection
• Revision History, on page 223
• Feature Description, on page 223

Revision History
Revision Details Release

First introduced. 21.13 (2/26/2019)

Feature Description
FUI Redirection is supported in the CUPS architecture. The Final-Unit-Indication AVP can be present in the
CCA from the server to indicate that the given quota is the final quota from the server and the corresponding
action as specified in the AVP needs to be taken.
If the Final-Unit-Indication AVP is present at MSCC level, and if the Final-Unit-Action AVP is set to
TERMINATE, a CCR-Update is sent at the expiry of the allotted quota and report the usage of the category
that is terminated.
In the Final-Unit-Indication AVP, if the Final-Unit-Action is REDIRECT or Redirect-Server AVP is present
at command level, redirection is performed.
The redirection takes place at the end of consumption of quota of the specified category. The Gy sends a
CCR-Update without any RSU or Rating-Group AVP so that the server does not give any more quotas. If the
Final-Unit-Action AVP is RESTRICT_ACCESS, then according to the settings in Restriction-Filter-Rule
AVP or Filter-Id AVP. Gy sends CCR-Update to the server with used quota.
With this release, the following functionalities are supported:
• The FUI-Redirection with HTTP URL.
• The FUI-Redirection is done for the HTTP GET request.
• Only the following CLI: diameter redirect-validity-timer immediate, is supported
• As per the 3GPP specification, Redirected-Traffic will also get redirected if the rule is executed from
FUI-Redirect. However, provision to allow redirected-traffic to pass through is not present but the CLI
behavior with respect to no diameter fui-redirected-flow allow behavior is implemented.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
223
 Cisco Confidential - Limited Release
Gy Multiple MSCC and FUI-Redirection
Limitations

Limitations
• The FUI-Redirection along with Filter-Ids/Filter-Rules are not supported.
• Appending the Original URL is not supported.
• Token based mechanism to exit Redirection is not supported.
• The default option traffic-start in the CLI: diameter redirect-validity-timer, is not supported.
• The WSP protocol is not supported in CUPS.
• The CLI: redirect-require-user-agent, is not supported. Even if the user-agent is not configured,
redirection is functional.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
224
 Cisco Confidential - Limited Release

CHAPTER 31
Idle Timer for SAE-GW Sessions
• Revision History, on page 225
• Feature Description, on page 225
• Limitations, on page 225
• Configuring Idle Timer for SAE-GW Sessions, on page 226

Revision History
Revision Details Release

First introduced. 21.10 (8/14/2018)

Feature Description
An Idle Timer is supported to identify and remove idle sessions that occur in the SAE-GW.
A session becomes idle in some cases where the session is removed from other network nodes, but due to a
technical mishap the session could still remain on the SAE-GW leading to resources being held by these idle
sessions.
The Idle Timer, once configured, removes those sessions that remain idle for longer than the configured time
limit effectively utilizing the system capacity.

Important This feature is currently restricted to Pure-P and Collapsed Call.

Limitations
The Idle Timer feature does not support recovery of Idle Timer in case of redundancy events.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
225
 Cisco Confidential - Limited Release
Idle Timer for SAE-GW Sessions
Configuring Idle Timer for SAE-GW Sessions

Configuring Idle Timer for SAE-GW Sessions

The Idle Timer is configurable at APN level.
Use the following commands to configure the idle timer for SAE-GW sessions:
configure
context context_name
apn apn_name
timeout idle timeout_value
no timeout idle
default timeout idle
end
• no: Disables the idle timer configuration.
• default: Configures the default value for subscriber’s time out settings. The default idle timeout value
is 0.
• idle timeout_value: Designates the maximum duration a session can remain idle, in seconds, before
system automatically terminates the session. Must be followed by number of seconds between 0 and
4294967295. Zero indicates function is disabled.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
226
 Cisco Confidential - Limited Release

CHAPTER 32
Indirect Forwarding Tunnel
• Revision History, on page 227
• Feature Description, on page 228
• How It Works, on page 228
• Configuring Indirect Forwarding Tunnel, on page 229
• Monitoring and Troubleshooting, on page 229

Revision History
Revision Details Release
In this release, new CLI commands has been introduced to enable or 21.14.c0
disable the feature. By default, the Indirect Forwarding Tunnel (IDFT)
feature in CUPS is disabled.
This feature is not fully qualified in this release.

In this release, support is added for IDFT creation of Sx Failure 21.14.cx

Handling for Pure-S and Collapsed PDN.
This feature is not fully qualified in this release.

In this release, support has been added for the following: 21.14.a2
• IDFT creation of Pure-S, Collapsed, and combination of Collapsed
and Pure-S multi-PDN with multiple bearers.
• Deletion of IDFT PDN, clear sub/delete from MME/P-GW.

This feature is not fully qualified in this release.

In this release, support is added for creation of IDFT for 21.14.CA0

Collapsed/multi-PDN/multi-bearers.
This feature is not fully qualified in this release.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
227
 Cisco Confidential - Limited Release
Indirect Forwarding Tunnel
Feature Description

Feature Description
SAEGW supports Indirect Forwarding Tunnel (IDFT) procedures for creation and deletion, which are applicable
for Pure-S and Collapsed calls with dedicated bearers. This feature is applicable for IDFT support with S-GW
Relocation.

Note The IDFT in CUPS is a CLI-controlled feature. By default, the IDFT feature in CUPS is disabled.

How It Works
Call Flow

Supported Functionality
The IDFT feature supports the following functionalities:
• Create IDFT request for Collapsed, Pure-S, combination of Collapsed and Pure-S multi-PDN calls with
multiple bearers.
• Data transfer on downlink and uplink IDFT bearers.
• Deletion of IDFT request from MME. Also, timer-based deletion of IDFT bearer after expiration of a
default value of 100 seconds, if the MME does not send an IDFT request for deletion.
• Deletion of IDFT PDN, including Clear sub/Delete from MME/P-GW, when normal PDN goes down.
• IDFT creation of Sx Failure Handling for Pure-S and Collapsed PDN.

Important Transport GTP-U address capability is assumed to be same across eNodeB and S-GW.

Limitations
The IDFT feature has the following limitations:
• Message interaction and collision during IDFT PDN establishment or deletion with any other procedure
is not supported.
• S11/S5 and Sx Path Failure Handling on non-IDFT PDN is not supported when IDFT PDN is Active.
• Deletion of partial dedicated bearers in IDFT connected-state is not supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
228
 Cisco Confidential - Limited Release
Indirect Forwarding Tunnel
Configuring Indirect Forwarding Tunnel

Configuring Indirect Forwarding Tunnel

This section describes the CLI commands available in support of IDFT feature.

Enabling Indirect Forwarding Tunnel Feature

On Control Plane, use the following CLI commands to enable or disable the IDFT feature.
configure
context context_name
sgw-service service_name
[ default | no ] egtp idft-support
end
NOTES:
• idft-support: Enables/Disables the IDFT feature in CUPS.
• By default, the IDFT feature is disabled and this CLI command is applicable on run-time change.

Verifying the Indirect Forwarding Tunnel Feature

show sgw-service name <service_name>
On Control Plane, the output of this CLI command has been enhanced to display if the IDFT feature is enabled
or disabled.
• IDFT-Feature Support for CUPS : Enabled/Disabled

Monitoring and Troubleshooting

This section provides information regarding the CLI commands available in support of monitoring and
troubleshooting the feature.

Show Commands Input and/or Outputs

This section provides information regarding show commands and their outputs in support of the feature.

show sub saegw-o full all

On Control Plane, use this command to see the IDFT Local and Remote TEID data. The following is a sample
output:
Indirect Fwding : Active
DL fwd local addr: 1.1.1.4 DL fwd remote addr: 1.1.1.2
DL fwd local teid: [0x80028004] DL fwd remote teid: [0x2002d2e5]
UL fwd local addr: 1.1.1.4 UL fwd remote addr: 1.1.1.2
UL fwd local teid: [0x8002a004] UL fwd remote teid: [0x20042bca]

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
229
 Cisco Confidential - Limited Release
Indirect Forwarding Tunnel
show sub user-plane-only callid <call-id> pdr all

show sub user-plane-only callid <call-id> pdr all

On User Plane, use this command to see the PDR or FAR created for IDFT. The following is a sample output:

Important IDFT PDRs will have ACCESS as the source and destination interface type.

+-----Source Interface: (C) - Core (A) - Access

|-----Type (P) - CP-function (.) - Unknown
|
|+----Destination Interface: (C) - Core (A) - Access
||----Type (P) - CP-function (.) - Unknown
||
||
||+---Rule-Type: (S) - Static (P) - Predefined
|||---Type (D) - Dynamic (.) - Unknown
|||
|||
vvv PDR-ID Associated FAR-ID Associated URR-ID(s) Associated QER-ID(s)
--- ------ ----------------- -------------------- --------------------
ACS 0x0001 0x8001 n/a 0x80000001
CAS 0x0002 0x8002 n/a 0x80000001
ACD 0x0003 0x0003 0x00000007 0x00000002
n/a 0x80000003
CAD 0x0004 0x0004 0x00000007 0x00000002
n/a 0x80000003
CAD 0x0005 0x0005 0x00000000 n/a
ACD 0x0006 0x0006 0x00000000 n/a
CAD 0x0007 0x0007 0x00000000 n/a
ACD 0x0008 0x0008 0x00000000 n/a
AAD 0x0009 0x0009 0x00000000 n/a
AAD 0x000A 0x000A 0x00000000 n/a
AAD 0x000B 0x000B 0x00000000 n/a
AAD 0x000C 0x000C 0x00000000 n/a

Total subscribers matching specified criteria: 1

show sub user-plane-only full all

Important Data statistics on IDFT PDRs are captured in the same way as existing PDR statistics. However, it is captured
with a limitation – Statistics for DL and UL IDFT will be incremented in Pkts-Down and Bytes-Down category.
The following is sample output:

Static & Predef Rule Match stats:

Rule Name Pkts-Down Bytes-Down Pkts-Up Bytes-Up Hits Match-Bypassed
FP-Down(Pkts/Bytes) FP-Up(Pkts/Bytes)
-------------------- ---------- ---------- ---------- ---------- ---------- --------------
------------------- -----------------
catchall 0 0 3 1368 3 0
0/0 0/0

Dynamic Rule Match stats:

PDR Id Pkts-Down Bytes-Down Pkts-Up Bytes-Up Hits Match-Bypassed
FP-Down(Pkts/Bytes) FP-Up(Pkts/Bytes)
-------- ---------- ---------- ---------- ---------- ---------- --------------
------------------- -----------------
0x0004 2 856 0 0 2 0 0/0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
230
 Cisco Confidential - Limited Release
Indirect Forwarding Tunnel
show sub user-plane-only full all

0/0
0x000b 2 856 0 0 2 0 0/0
0/0
0x000c 2 168 0 0 2 0 0/0
0/0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
231
 Cisco Confidential - Limited Release
Indirect Forwarding Tunnel
show sub user-plane-only full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
232
 Cisco Confidential - Limited Release

CHAPTER 33
IP Pool Management
This chapter includes the following topics:
• Revision History, on page 233
• Feature Description, on page 234
• How It Works, on page 234
• Configuring IP Pool Management, on page 240
• Monitoring and Troubleshooting, on page 242

Revision History
Revision Details Release

With this release, "IP pool per context" and "no-chunk-pool" functionality are 21.20.4
added.

Hold Timer functionality is supported in 21.16.c15, 21.17.8, and 21.20.x and 21.16.x, 21.17.x, and 21.20
later releases.

With this release, the cups chunk-allocate-timer allocate_timer_seconds 21.9 (7/16/2018)

chunk-release-timer release_timer_seconds CLI command is deprecated, and
replaced by cups chunk-threshold-timer threshold_timer_seconds and cups
min-chunks-threshold-per-pool threshold_percent CLI commands.

With this release, support has been added for User Plane De-Registration and 21.9 (6/29/2018)
handling of Pool Threshold.

First introduced. 21.9 (5/4/2018)

• The IP Pool Management feature is not fully qualified in this release.
• Sx Association procedure is not fully qualified in this release.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
233
 Cisco Confidential - Limited Release
IP Pool Management
Feature Description

Feature Description
When the IP Pool is unused for a large part, it is not an efficient way of utilizing the resources. The User Plane
(UP), which are short of IP resources, can benefit if the unused resources are available to them in a dynamic
way.
In the CUPS architecture, there is a centralized Control Plane (CP), large number of UPs, and an automatic
and efficient way of managing IP Pool across UPs for the following deployments:
• Co-Located CUPS
• Remote CUPS

How It Works
In CUPS architecture, the PDN/IP context at CP distributes the IP chunk resources among multiple registered
UPs in a dynamic way. Following sections describes the overall solution.

Handling UP De-Registration
UP de-registration is triggered in the following scenarios:
• Graceful de-registration from UP—In this scenario, Control-Plane-Group association is removed with
User-Plane-Service CLI. The IP addresses are released at sessmgr level on CP.
• UP connection failure from CP—This scenario occurs either because of miss of heartbeat from UP to
CP, or because UP restarts and CP is communicated about it. When UP restarts, it implies that the
reception of a new Restart-Counter at CP of the specified UP.

After the UP de-registration is triggered, the VPNMGR task on CP validates the identity and address of UP
with the information available in the VPNMGR database. In case of mismatch, VPNMGR shows the failure
message. In case of match, the validation is successful. On successful validation, VPNMGR takes all the
assigned and unassigned chunks from both IPv4 and IPv6 pools from the specified UP.
Whether the UP has some used or all unused IPs, VPNMGR starts a 2-minutes timer before carrying out
forceful de-registration of the UP. During forceful de-registration, all IP addresses are deleted from VPNMGR
database locally, session entries are removed, and all the chunks are placed to the main address pools at CP.

Hold Timer
Hold Timer is configured per pool for IPv4 dynamic pools. Static pools and IPv6 pools aren't considered. If
Hold Timer isn't configured, an IP address moves from Free to Used state when allocated, and back to Free
state when the session is released. With the Hold Timer configured in the pool, a released IP address is moved
to Hold state. For the configured Hold Timer duration, the IP address is kept in Hold state and can be reused
when the same subscriber attaches again. Since it's in Hold state, the IP address isn't assigned to any other
subscriber. After the Hold Timer expiry, the IP address moves to Release state and it's reused when all the
free IP addresses are exhausted.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
234
 Cisco Confidential - Limited Release
IP Pool Management
Hold Timer

In case of UP deregistration, all IP addresses in Hold state are moved to Free state since the UP details (UP
ID and the memory that holds details of UP) aren't preserved at the CP. This might result in the IP address
being reused for a different subscriber. Also, VPNMgr recovery and ICSR are supported for Hold addresses.

Address State Change

Following call flow describes the address state change with Hold Timer configured.
Figure 8: Address State Change with Hold Timer

Following call flow describes the address state change without Hold Timer configuration.
Figure 9: Address State Change without Hold Timer

Configuring Hold Timer

Use the following configuration to enable Hold Timer feature in CUPS.
configure
context context_name
ip pool address-hold-timer seconds
end
NOTES:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
235
 Cisco Confidential - Limited Release
IP Pool Management
IP Pools per Context

• When the feature is enabled, and an active subscriber is disconnected, the IP address is held or considered
still in use, and isn't returned to the free state until the address-hold-timer expires. This enables subscribers
who reconnect within the length of time specified (in seconds) to obtain the same IP address from the
IP pool. seconds is the time in seconds and must be an integer from 0 through 31556926.

Use the show ip pool address pool-name pool_name CLI command to check the status of all IP addresses
in a pool. It also shows the remaining hold time for the held addresses.

IP Pools per Context

You can configure 600 IP pools per UP group in a single context at CP. Also, 2000 IPv4 and 256 IPv6 pools
can be configured per context in CP which can be distributed among various UP groups with upper limit of
600 pools per UP. The functionality includes:
• UP group can have a maximum of 600 IP pools for all possible combinations of pool type.
• Pools can be either static, dynamic, or combination of both.
• Pools can be all IPv4, IPv6, or combination of both.
• Out of 600, a UP group can have a maximum of 256 IPv6 pool (context level limitation that is same as
ASR5500). All 600 pools can be IPv4.
• If more than 600 IP pools are configured in a UP group, then it can't be determined as to which 600
pool/pool chunks will be allocated to a UP.
• The CP maintains count of routes that are installed at UP. If it exceeds 6000 pool routes (context level
limitation that is same as ASR5500), then no new chunk is allocated to UP even if it reaches the threshold
for overuse. Similarly, if new IP pool is dynamically allocated and 6000 pool routes are already installed,
then no new chunk is allocated from that pool even if pool count is less than 600 for that UP.

As part of this feature, the dynamic IPv4 and IPv6 pool count is replaced with total IPv4 and IPv6 pool count
in the show ip user-plane verbose CLI command. Also, the output of the CLI command is enhanced to
display Total Pool Kernel Routes and Max Pool Kernel Routes fields.

IP Resource Management
In CUPS architecture, the CP has all the IP Pool configurations in PDN/IP context. In compliance with 3GPP
standards, the UP registers with CP by Sx Association Request/Response procedure.
During the registration process, the CP finds out all the APNs which are being served by the particular UP,
and the associated Pool configuration in each APN. The CP allocates some of the IP chunk resources to a
particular UP and sends over the Sx Association Update Request/Response procedure. This information is
sent to PDN/IP context instance at UP.
After UP registration is successful, the PDN/IP instance initiates sending of IP chunk resource information
to the UP from the Pool. This IP chunk resource information is sent to the UP on Proprietary/Custom IE on
Sx Association Update Request/Response message. The PDN/IP instance at UP announces the BGP routes,
on per chunk basis, which is received from the CP.
Each UP, which is registered with the CP, is identified using "Peer Id" and the Node ID.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
236
 Cisco Confidential - Limited Release
IP Pool Management
IP Resource Replenishment/Withdrawal Procedure

IP Resource Replenishment/Withdrawal Procedure

For efficient utilization of IP resources, the CP allocates IP resources to UP on need basis. And so, it supports
replenishment and withdrawal procedures for IP chunk resources.
Based on the threshold logic in CP, it monitors the usage of IP resources in each UP on pool-level basis. If
the overall IP chunk usage of the UP crosses certain threshold, the CP sends additional IP chunk resources to
the UP.
If certain IP chunks in the UP are not utilised, and idle for certain duration, the CP withdraws those IP chunk
resources from respective UPs. For details, see Configuring Percentage of Chunks Per Pool section.

No-chunk-pool for One UP per UP Group

Feature Description
For static IP address allocation, the SessMgr requests for specific IP address. The VPNMgr searches for that
specific IP address. If the chunk is already allocated to a particular UP, then the VPNMgr allocates that address
and responds to the UP which serves the call. For static IPv4v6 call, the requested IPv4 and IPv6 address
might belong to different UPs and therefore, success of IPv4v6 can't be guaranteed unless there's only one
UP per UP Group. So, for successful static IPv4v6 call, only one UP per UP group can be configured. For
one UP per UP Group use case, pool chunking isn't recommended as only one UP uses that pool, and the
entire pool can be allocated to the UP rather than in chunks. Also, there are certain use cases to contain one
APN to one UP. To support both these use cases, an option to not chunk the pool in CUPS architecture is
introduced.
Without the no-chunk-pool functionality, if number of usable addresses are less than the chunk size, then
minimum of two chunks were configured.
With no-chunk-pool functionality, a pool can be configured without being chunked. The entire pool is allocated
to the UP that is first to request for the pool.

Note The no-chunk-pool functionality is recommended only for a setup with one UP per UP Group. It's not
recommended for multi-UP per UP Group.

How it Works
The no-chunk-pool functionality includes:
• When a pool is configured as no-chunk-pool, then pool itself is considered as a chunk and the entire pool
is allocated to the UP that is first to request for the pool.
• No-chunk-pool can be public, private, or static.
• No-chunk-pool can be configured within VRF.
• For multi-UP per UP Group, the entire dynamic no-chunk-pool is allocated to the UP that is first to do
Sx-association.
• For multi-UP per UP Group, the static no-chunk-pool is allocated in round-robin algorithm among
currently servicing UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
237
 Cisco Confidential - Limited Release
IP Pool Management
Static IP Pool Management

• For multi-UP per UP Group, the dynamically added new pool can get allocated to any UP in UP Group
and can’t be deterministically known.

Configuring No-chunk-pool
Use the following configuration to enable no-chunk-pool functionality.
configure
context context_name
cups enable
ip pool pool_name ip_address/subnet_mask no-chunk-pool
ipv6 pool pool_name prefix ip_address/length no-chunk-pool
exit
The no-chunk-pool can be identified from the output of the following CLI commands if the "total-chunks"
field displays 1 (one) for that particular pool.
• show ip pool-chunks pool-all
• show ipv6 pool-chunks pool-all

Static IP Pool Management

In CUPS architecture, the strategy to manage static IP pools differs from dynamic pool managemnent. Static
IP pools are broken down into "static-chunks" similar to how dynamic pools are chunked. However, these
static chunks are not distributed to the UPs and remain at the CP until a UE requests for the first static address
in a certain Static-IP-Chunk during session creation.
The CP selects the UP using the round-robin algorithm and the entire Static-IP-Chunk, to which the requested
static address belongs, is assigned to the selected UP. Therefore, whenever any UE requests static addresses
(IPv4 or IPv6) from that chunk, the UE is assigned that UP.

Note • Within dynamic pools, "allow static" is not supported.

• IPv4v6 static PDP is not supported with multiple UPs in a UP Group.
• For the static IPv4v6 PDNs to be successful, both IPv4 and IPv6 addresses must be on the same UP.
Only way to ensure this is to have a single UP in the UP group.
• For the multi-PDNs on same APN to be successful, with one PDN as static and the other as dynamic,
both addresses must be on same UP. Only way to ensure this is to have a single UP in the UP group.
• In case of static IP pool, address is already decided by UE and so, the benefit of UP selection does not
remain.

UP Selection
In CUPS architecture, during the establishment of sessions, UP selection happens among the registered UP.
There are various ways to select UP. In earlier releases, Round-Robin Algorithm based UP selection was
supported. Currently, least connection User Plane selection algorithm is supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
238
 Cisco Confidential - Limited Release
IP Pool Management
Supported Functionality

Supported Functionality
The following functionalities are supported as part of the IP Pool Management feature.
• IPv4, IPv6 Public, and private pool-based IP address allocation.
• IPv4 static type address allocation.
• Session Manager recovery and VPN Manager recovery for active calls types.
• CP to CP Interchassis Session Recovery (ICSR) support.
• Hold-timer for IPv4 pools.
• Busy-out (basic functionality) for IPv4 and IPv6 pools.

Limitations
Following are the known limitations and restrictions of this feature for this release:
• The “allow-static” type pool configuration isn't supported.
• Configure the cups enabled CLI before you add a pool in IP context to enable IP Pool Management
functionality in CUPS mode.
• IPv4v6 static PDP isn't supported with multiple UPs in a UP Group.
• The output of the following CLI commands displays all pools with maximum of 2048 chunks per pool:
• show ipv6 pool-chunks up-id up_id
• show ipv6 pool-chunks pool-name ipv6_pool_name
• show ip pool-chunks up-id up_id
• show ip pool-chunks pool-name ipv4_pool_name

• Following are not supported in the CUPS architecture:

• IPv6 – address hold timer is not supported.
• PDN v4v6 – address hold timer is not supported.

• Upon UE reattach, CP needs to select the same UP session (as IP address is already advertised by that
UP in the earlier session). Hence there is no UP load based selection or location based UP Selection
possible.

• Hold timer value of 0 is not supported.

• Recovery of Hold timer is supported for up to 1000 address per session manager.
• Reload chassis results in the standby chassis losing the hold timer information.

• Any change to the Hold timer value also requires a Sx re-establishment like it happens for any other pool
configuration.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
239
 Cisco Confidential - Limited Release
IP Pool Management
Configuring IP Pool Management

Configuring IP Pool Management

This section provides information about the CLI commands available in support of this feature.

Important • In an earlier release, User Plane profile configuration was required for S-GW and P-GW. With this
release, User Plane profile configuration is no longer required in S-GW and P-GW for UP selection.
Also, it is not required to be associated with IP pool configuration.
• Same PDN context should be present at both CP and UP.
• IP context name, which is specified in APN configuration, should be same for both CP and UP.

For guidelines around planning IP Pool and User Plane grouping in your network, contact your Cisco Account
representative.

At Control Plane
Enabling IP Context for IP Pool Management
Use the following CLI commands to enable IP context for IP Pool management.
configure
context context_name
cups enable
end

Configuring Custom Threshold Timer

Important In 21.9 (mid-July) and later releases, the cups chunk-allocate-timer allocate_timer_seconds
chunk-release-timer release_timer_seconds CLI command is deprecated, and replaced by cups
chunk-threshold-timer threshold_timer_seconds and cups min-chunks-threshold-per-pool threshold_percent
CLI commands.

There is a threshold timer for chunk redistribution among UPs. By default, for sending chunk into an over
utilized UP, check is carried out every 60 seconds, and for removing chunk from an underutilized UP, check
is carried out every 300 seconds. For custom threshold timer, use the following CLI commands:
configure
context context_name
cups chunk-allocate-timer allocate_timer_seconds chunk-release-timer
release_timer_seconds
end
NOTES:
• This is an optional configuration. If not configured, then by default the allocate threshold is 60 seconds
and the release threshold is 300 seconds.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
240
 Cisco Confidential - Limited Release
IP Pool Management
At Control Plane

• Use the default cups chunk-allocate-timer chunk-release-timer CLI command to revert back the
chunk-allocation and chunk-release timer to 60 and 300 respectively.
• If the release timer is configured to be less than the allocate timer, then it is overwritten with the value
that equals to the allocate timer.

Configuring Chunk Threshold Timer

Use the following CLI commands to configure CUPS IP pool chunk threshold timer for a context.
configure
context context_name
cups chunk-threshold-timer threshold_timer_seconds
end
NOTES:
• threshold_timer_seconds: Specifies the chunk threshold timer value in seconds, integer 30 to 300. Default
= 60 seconds.
• Use the default cups chunk-threshold-timer CLI command to set the default value of 60 seconds.
• In releases prior to 21.9 (mid-July), allocation of new chunks to UP and release of chunks from
underutilized UP use to occur based on allocation and release timers, respectively. With 21.9 (mid-July)
and later releases, only single threshold timer exists, based on which the allocation and release of chunks
occur periodically.

Configuring Percentage of Chunks Per Pool

Use the following CLI commands to configure minimum percentage of chunks per pool in a context.
configure
context context_name
cups min-chunks-threshold-per-pool threshold_percent
end
NOTES:
• threshold_percent: Specifies the minimum chunks in percentage of 0 to 50. Default = 10.
• Use the default cups min-chunks-threshold-per-pool CLI command to set the default value of 10
percent.
• Chunks are released periodically only when free chunks with particular pools, at CP, are less than the
percentage configured with this CLI command.
• When minimum chunks equals to, or falls below, the configured percentage, a check is done to
ascertain if there is any UP that has less than 50% utilization and has more than 2 free chunks. If
there is, then one is taken back from each underutilized UP from that particular pool.

• Warning log is generated for: periodicity = chunk-threshold-timer; till minimum chunks in CP VPNmgr
are restored.
• UP lockdown period on registration: For first five (5) minutes of a UP registration, no chunks are taken
back from that UP and sent to another UP even if other UPs are in need of chunks.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
241
 Cisco Confidential - Limited Release
IP Pool Management
Configuring Chunk-size Value

Configuring Chunk-size Value

Use this CLI command to specify the size of the chunk for the particular IP pool during pool creation.
configure
context context_name
ip pool pool_name prefix mask chunk-size chunk_size_value
end
NOTES:
• Chunk-size can be configured only during the configuration of IP pool for the first time along with
prefix/mask.
• Chunk-size value must be in powers of 2 and range is 16 through 8192.
• Default Value: 1024

At User Plane
For IP context in UP, there is no requirement for IP Pool configuration, or to use the cups enabled CLI
command.

Configuring User Planes for a System

Use the following CLI commands to configure maximum number of User Planes expected to be functional
in a system.
configure
context context_name
cups max-user-planes value
end
NOTES:
• cups max-user-planes value: The value should be in the range of 1-1000. The default value is 10.
Use this CLI command to tune the initially allocated chunks on Sx-association. It can't be used to restrict
the addition of new UPs into a system.
• Use the default cups max-user-planes CLI command to revert back the maximum user-planes value to
10.

Monitoring and Troubleshooting

This section provides information regarding monitoring and troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature
at CP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
242
 Cisco Confidential - Limited Release
IP Pool Management
show ip pool-chunks pool-name <pool-name>

show ip pool-chunks pool-name <pool-name>

The output of this command displays all the chunks in the specified IPv4 pool.
• chunk-id
• pool-id
• up-id
• total-addr
• free-addr
• used-addr
• hold-addr
• release-addr
• busyout-free
• busyout-used

show ip pool-chunks pool all

The output of this command displays the IPv4 pool chunks that are allocated to all the User Planes.
• chunk-id
• pool-id
• up-id
• total-addr
• free-addr
• used-addr
• hold-addr
• release-addr
• busyout-free
• busyout-used

Note The above fields are also displayed for the show ipv6 pool-chunks pool all CLI command except for the
"hold-addr" and "release-addr" fields.

show ip pool-chunks up-id <up_id> user-plane-group name <grp-name>

The output of this command displays all the IPv4 chunks that are allocated to a specific User Plane.
• chunk-id

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
243
 Cisco Confidential - Limited Release
IP Pool Management
show ip user-plane chunks

• pool-id
• up-id
• total-addr
• free-addr
• used-addr
• hold-addr
• release-addr
• busyout-free
• busyout-used

show ip user-plane chunks

The output of this command displays IPv4 chunks allocated to each User Plane.
• up-id
• total-chunks
• free-chunks
• used-chunks
• full-chunks

Note The above fields are also displayed for the show ipv6 user-plane chunks CLI command.

show ip user-plane prefixes

The output of this command displays IPv4 prefixes allocated to each User Plane.
• up-id
• Total
• Free
• Used
• Hold
• Release
• Busyout-Free
• Busyout-Used

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
244
 Cisco Confidential - Limited Release
IP Pool Management
show ip user-plane verbose

Note The above fields are also displayed for the show ipv6 user-plane prefixes CLI command.

show ip user-plane verbose

The output of this command displays all the details related to a User Plane.
• User-plane Group Name
• User-plane ID
• User-plane address
• Sxmgr-id
• IPv4 Chunks
• Total
• Free
• Used
• Full

• IPv4 address
• Total
• Free
• Used
• Hold
• Release
• Busyout-Free
• Busyout-Used

• IPv6 Chunks
• Total
• Free
• Used
• Full

• IPv6 prefixes
• Total
• Free
• Used

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
245
 Cisco Confidential - Limited Release
IP Pool Management
show ip user-plane

• Busyout-Free
• Busyout-Used

• Total Pool count

• IPv4
• IPv6

• Total Pool Kernel Routes

• Max Pool Kernel Routes
• Total VRFs
• apn-without-pool-name-v4
• apn-without-pool-name-v6
• Pool-groups

show ip user-plane
The output of this command displays the details of all the User Planes that are registered with the VPN
Manager.
• up-id
• user-plane-address
• user-plane-group-name
• sxmgr-id

NOTES:
• Use the show ip user-plane up-idup_iduser-plane-group name grp-name to view the details of a
specific User Plane belonging to a specific User Plane group.

show ipv6 pool-chunks pool-name <pool-name>

The output of this CLI command displays all the chunks in the IPv6 pool.
• chunk-id
• pool-id
• up-id
• total-addr
• used-addr
• busyout-free
• busyout-used

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
246
 Cisco Confidential - Limited Release
IP Pool Management
show ipv6 pool-chunks up-id <up_id> user-plane-group name <grp-name>

show ipv6 pool-chunks up-id <up_id> user-plane-group name <grp-name>

The output of this command displays all the IPv6 chunks that are allocated to a specific User Plane.
• chunk-id
• pool-id
• up-id
• total-addr
• used-addr
• busyout-free
• busyout-used

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
247
 Cisco Confidential - Limited Release
IP Pool Management
show ipv6 pool-chunks up-id <up_id> user-plane-group name <grp-name>

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
248
 Cisco Confidential - Limited Release

CHAPTER 34
IP Source Violation
This chapter includes the following topics:
• Revision History, on page 249
• Feature Description, on page 249
• Configuring IP Source Violation, on page 249
• Monitoring and Troubleshooting, on page 250

Revision History
Revision Details Release

Added VPP behavior information for IP Source Violation configuration. 21.15.1

The IP Source Violation is fully qualified in this release. 21.9 (31/5/2018)

First introduced. 21.9 (5/4/2018)

The IP Source Violation feature is not fully qualified in this release.

Feature Description
The CUPS architecture supports packet source validation on the User-Plane. Source validation is useful if
packet spoofing is suspected or for verifying packet routing and labeling within the network.
The User-Plane checks the source IP address of the uplink data packet with the IP address of the UE for a
match and decides to either drop or permit the data packet further based on configured values.
An existing configuration, which is part of the non-CUPS architecture is implemented for this feature. The
ip source-violation command – part of the APN Configuration mode is used to implement packet source
validation.

Configuring IP Source Violation

Use the following configuration to enable or disable packet source validation for a given APN:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
249
 Cisco Confidential - Limited Release
IP Source Violation
Monitoring and Troubleshooting

configure
context context_name
apn apn_name
ip source-violation { ignore | check [ drop-limit limit ] [
exclude-from-accounting ] }
default ip source-violation
end
NOTES:
• default: Enables the checking of source addresses received from subscribers for violations, with a drop
limit of 10 invalid packets that can be received from a subscriber prior to their session being deleted.
• ignore: Disables source address checking for the APN.
The User Plane does not increment the IP source violation counter and the dropped packet statistics will
be zero. The User Plane would create a different Stream, and VPP sends these packets through fastpath
using the same Stream ID.
• check [ drop-limit limit ]: Default: Enabled, limit = 10.
Enables the checking of source addresses received from subscribers for violations. A drop-limit can be
configured to set a limit on the number of invalid packets that can be received from a subscriber prior to
their session being deleted.
limit: can be configured to any integer value between 0 and 1000000. A value of 0 indicates that all
invalid packets will be discarded, but the session will never be deleted by the system.
• exclude-from-accounting: Excludes the packets identified with IP source violation from the statistics
generated for accounting records.
When exclude-from-accounting is disabled:
• Dropped packets are not accounted. However, the packets that are sent from VPP are charged.
• Usage Report URR has dropped bytes.
• Packet drop counter increases.

When exclude-from-accounting is enabled:

• Dropped packets are not accounted.
• Usage Report URR will not have dropped packets.
• Packet drop counter increases.

Monitoring and Troubleshooting

This section provides information regarding monitoring and troubleshooting the IP Source Violation feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
250
 Cisco Confidential - Limited Release
IP Source Violation
show sub user-plane-only full all

show sub user-plane-only full all

On executing the above command, the following fields are displayed for this feature:
• ip source violations

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
251
 Cisco Confidential - Limited Release
IP Source Violation
show sub user-plane-only full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
252
 Cisco Confidential - Limited Release

CHAPTER 35
L2 Marking Support
• Revision History, on page 253
• Feature Description, on page 253
• How it Works, on page 253
• Configuring L2 Marking Support, on page 255

Revision History
Revision Details Release

First introduced. 21.15.1

Feature Description
The L2 Marking Support for CUPS enables marking of QoS Class Identifier (QCI) and Differentiated Services
Code Point (DSCP) derived L2 marking for CUPS. The QoS marking support is similar to the QoS marking
support that is supported on the non-CUPS platform, which ensures that the QoS treatment is maintained
when the packets traverse via the L2 routers.

How it Works
This section briefly describes how L2 marking works.

Basic Functionality
• The type of the L2 marking is decided at the Control Plane (CP) as per the Service-Configuration. The
types of L2 marking supported are DSCP-based, QCI-based, and None.
• When the User Plane (UP) comes up with a QCI value, the lookup is performed on the associated QCI-table
for the service. Based on the lookup, the priority is selected or decided for the corresponding QCI value.
• The selected Layer 2 marking type and priority is communicated to the UP in an Sx message.
• To support the passing of new information to the UP, a new custom IE is added to the FAR IE.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
253
 Cisco Confidential - Limited Release
L2 Marking Support
How it Works

• LAYER2 MARKING:
• TYPE PRIORITY: <type> <priority-value>
The new custom IE is defined with the type-number : 228

• When the L2 marking changes – type or priority, the same is communicated to the UP, when the bearer
update occurs.

Sx Interfaces Changes
Layer 2 Marking IE in FAR
To pass the L2 Marking information to the UP for the bearer, a new custom-IE is defined and the FAR is
modified to include it as follows:

Table 11: Layer 2 Marking Information Element

Information Condition / Comment Application IE ID

Elements
Sxa Sxb Sxc N4

Layer2 This IE shall indicate X X

Marking the type of the Layer2
Marking if present.

The Layer 2 Marking IE is encoded as follows:

Table 12: Layer 2 Marking IE Within PFCP FAR

Octet 1 and 2 Layer2 Marking IE Type = 228 (decimal)

Octets 3 and 4 Length = n

Information Condition / Comment Application

elements
Sxa Sxb Sxc N4

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
254
 Cisco Confidential - Limited Release
L2 Marking Support
Limitations

Octet 1 and 2 Layer2 Marking IE Type = 228 (decimal)

Octets 3 and 4 Length = n

Layer 2 Marking This IE identifies the Layer 2 X X Sxc N4

Marking to be applied for the
packets matching this FAR.
The length of the IE could be
either 0 or 1. The 1 byte contains
the following information.
• TYPE PRIORITY: <type>
<priority-value>
• Type : (1-DSCP, 2-QCI,
3-None) - beginning 2 Bits
Priority-Value: the last 6 bits
• Internal-Priority in case
of QCI/None type
• DCSP value in case of
DSCP type

Limitations
The following is the limitation for this feature in this release.
The change in the QCI table is not applied immediately to the subscriber. The change is applied only after
the bearer update.

Configuring L2 Marking Support

The following section provides information about the CLI commands available to enable or disable the feature.

Configuring Internal Priority

To configure internal priority in the QCI-mapping table for the GGSN, GTPv1 P-GW, and SAEGW calls,
use the following service specific configuration. This command in the GGSN service configuration overrides
the behavior of QCI-QOS-mapping for data packets only.
configure
context context_name
ggsn-service service_name
internal-qos data { dscp-derived | none | qci-derived }
{ no | default } internal-qos data { dscp-derived | none |
qci-derived }
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
255
 Cisco Confidential - Limited Release
L2 Marking Support
Associating QCI-QoS Mapping Table

Notes:
• no: Disables the specified functionality.
• default: Disables the functionality.
• dscp-derived: Data packets are marked at Layer 2 based on DSCP configured in qci-qos mapping table,
then if DSCP is not configured in the qci-qos mapping table then data packets are not marked.
• none: Data packets are not marked with Layer 2 (MPLS EXP/802.1P) marking.
• qci-derived: Data packets are marked at Layer 2 based on internal-qos-priority configured in qci-qos
mapping table. If internal-qos priority is not configured in the qci-qos mapping table, then the data packets
are not marked.

Associating QCI-QoS Mapping Table

Use the following commands to associate a QCI-QoS mapping table at the CP.
configure
context context_name
associate qci-qos-mapping { map_table_name map_table_name }
exit
NOTES:
• map_table_name map_table_name: Specifies the name of an internal table from which to map the QoS
to L2 values.
map_table_name must be a string of 0 through 80 characters.
• This command is disabled by default.

Configuring QCI Derived L2 Marking

Use the following commands to:
• Create or modify a Layer 2 mapping table.
• Enter the QoS L2 Mapping Configuration Mode to map internal QoS priority to Layer 2 QoS values on
the User Plane (UP).

configure
qos l2-mapping-table { name map_table_name| system-default }
exit
NOTES:
• name map_table_name: Specifies the name of QoS mapping table from which to map QoS to L2 values.
It enables internal mapping to L2 values like 802.1p, mpls, and so on.
map_table_name must be an alphanumeric string of 0 through 80 characters.
• system-default : Configures the system default mapping. The system default is always associated as the
default for every VRF or Context.
• This command is enabled by default.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
256
 Cisco Confidential - Limited Release
L2 Marking Support
Associating L2 Mapping Table

Associating L2 Mapping Table

Use the following commands to associate the configured L2 mapping table to a given VRF or Context.
configure
context context_name
associate l2-mapping-table name table_name
exit
NOTES:
• l2-mapping-table name table_name: Specifies the name of an internal table from which to map QoS
to L2 values.
map_table_name must be an alphanumeric string of 0 through 80 characters.
• This command is enabled by default.

Configuring DSCP Derived L2 Marking

Use the following commands to modify the Differentiated Services Code Point (DSCP) to Class of Service
(CoS) mapping on the User Plane (UP).
configure
qos ip-dscp-iphb-mapping dscp dscp_value internal-priority cos
class_of_service_value
exit
NOTES:
• ip-dscp-iphb-mapping: Manages mapping of the DSCP information in a packet to the internal QoS
marking.
“ip-dscp-iphb-mapping” is a global table per UP.
• dscp dscp_value: Maps the IP DSCP values to the internal QoS.
dscp_value must be a hexadecimal number between 0x0 and 0x3F.
• internal-priority cos class_of_service_value: Maps to the internal QoS priority or CoS.
class_of_service_value must be a Hexadecimal number between 0x0 and 0x7.
• This command is enabled by default.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
257
 Cisco Confidential - Limited Release
L2 Marking Support
Configuring DSCP Derived L2 Marking

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
258
 Cisco Confidential - Limited Release

CHAPTER 36
L3, L4, and L7 Rule Combination in Ruledef
• Revision History, on page 259
• Feature Description, on page 259
• How it Works, on page 259
• Configuring the L3, L4, and L7 Rule Combination in Ruledef Feature, on page 260
• Monitoring and Troubleshooting, on page 261

Revision History
Revision Release
Details
First 21.22.1
introduced.

Feature Description
Using the L3, L4, and L7 Rule Combination in Ruledef feature, you can allow and categorize traffic into
specific Rating Group (RG) for the following:
• Specific IP addresses
• Ports
• Uniform Resource Locators (URLs)

The feature increases the scalability of the host pool from 256 to 512. The feature allows and defines a new
url-sni-pool configuration with 256 entries in a single pool. The entries can be a mix of URL and Server
Name Indication (SNI) values. The system-wide limit of URL-SNI pools is 384 entries.

How it Works
The feature enables you to define a list of URLs or SNIs for the url-sni-pool configuration. The system uses
a pool of URLs or SNIs as an L7 filter within a ruledef. A ruledef can contain a combination of hostpool,

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
259
 Cisco Confidential - Limited Release
L3, L4, and L7 Rule Combination in Ruledef
Configuring the L3, L4, and L7 Rule Combination in Ruledef Feature

portmap, and url-sni pool match. The system matches the url-sni-pool configuration along with the other rule
lines criteria without occupying any of the 32 existing rule lines.

Configuring the L3, L4, and L7 Rule Combination in Ruledef

Feature
The new URL-SNI Pool Configuration mode is available under ACS Configuration mode. Use the following
configuration to enable the feature.
configure
active-charging service service_name
url-sni-pool pool_name
http url { contains | starts-with | ends-with | = | !contains |
!starts-with | !ends-with | != } url_name
tls sni { contains | starts-with | ends-with | = | !contains |
!starts-with | !ends-with | != } sni_identity
ruledef ruledef_name
ip server-ip-address host_poolname
tcp either-port port-map port_mapname
http-tls url-sni-pool pool_name
end

Note • The system configures the ruledef with the default all-lines AND option or multi-line-or-all-lines option.
• When the url-sni-pool rule line is configured, the URL or SNI value is always matched regardless of
the AND or OR match operation.
• When the AND operation is configured, all the other rule lines is matched in addition to the URL or SNI
value in the pool.

Note The AND operation is the default configuration.

• After configuring the OR operation, the system matches the following values for the rule action to take
effect:
• Any one of the other rule lines.
• URL or SNI

Verifying the L3, L4, and L7 Rule Combination in Ruledef Feature Configuration
Use the following show CLI commands to verify the url-sni-pool configuration.
• On Control Plane: show configuration active-charging service name service_name
For example, the following is a partial output of the show CLI command:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
260
 Cisco Confidential - Limited Release
L3, L4, and L7 Rule Combination in Ruledef
Monitoring and Troubleshooting

url-sni-pool url_pool1
http url contains google.com
tls sni contains gmail.com

• On User Plane: show user-plane-service url-sni-pool name pool_name

For example, the following is a partial output of the show CLI command:
url-sni-pool url_pool1
http url contains google.com
tls sni contains gmail.com

Total url-pool(s) found: 1

Monitoring and Troubleshooting

Show commands and Outputs
This section provides information about the show CLI commands available in support of the feature.

show configuration active-charging service name <service_name>

Use this CLI command in Control Plane to display the url-sni-pool attachment to the ruledef.
The following is a partial sample output:
ruledef special_charging_group1
ip server-ip-address range host-pool IP_FREE_MUSIC
tcp either-port range port-map PORT_FREE_MUSIC
http-tls url-sni-pool url_pool1

show user-plane-service ruledef name <ruledef_name>

Use this show CLI command in User Plane to display the url-sni-pool attachment to the ruledef.
The following is a partial sample output:
Ruledef Name: special_charging_group1
ip server-ip-address range host-pool IP_FREE_MUSIC
tcp either-port range port-map PORT_FREE_MUSIC
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Attached Url-Sni-Pool: url_pool1
Multi-line OR: Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
261
 Cisco Confidential - Limited Release
L3, L4, and L7 Rule Combination in Ruledef
Show commands and Outputs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
262
 Cisco Confidential - Limited Release

CHAPTER 37
L7 PCC Rules
• Revision History, on page 263
• Feature Description, on page 264
• How It Works, on page 264

Revision History
Revision Details Release

In this release, support is added for RTP dynamic flow detection. 21.20

In this release, support is added for SIP analyzer. 21.19

In this release, support is added for HTTP URL Filtering. 21.18.1

In this release, support is added for DNS Snooping. 21.17 (12/19/2019)

In this release, support is added for Content Filtering. 21.15.2 (9/30/2019)

In this release, limitation section is updated to include the following: 21.15.1 (9/13/2019)
• X-Header Encryption with RSA and RC4MD5 is supported but not
supported with AES.
• Following X-Header fields insertion is not supported in a packet: QoS,
UIDH, Customer ID, Hash Value, Time of the Day, Radius String,
Session-Id, Congestion Level, User-Profile.
• X-Header Insertion in Response packet is not supported.
• Monitor protocol for X-Header is not supported.

In this release, supported is added for X-Header insertion. 21.15.M0

First introduced. 21.14.M0 (5/31/2019)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
263
 Cisco Confidential - Limited Release
L7 PCC Rules
Feature Description

Feature Description
With this feature, the L7 analyzer functionality is supported in the CUPS architecture.
The following L7 analyzers are supported:
• HTTP
• HTTPS
• RTP/RTSP
• FTP
• DNS
• Content Filtering
• DNS Snooping

The following charging actions are supported:

• Discard
• Terminate Flow
• Redirect (if applicable)

How It Works
This section provides a brief overview of the L7 analyzer functionality that are supported as part of this feature.

Content Filtering
Content Filtering is an in-line service available for 3GPP and 3GPP2 networks to filter HTTP requests from
mobile subscribers based on the URLs in the requests. This enables operators to filter and control the content
that an individual subscriber can access, so that subscribers are inadvertently not exposed to universally
unacceptable content and/or content inappropriate as per the subscribers’ preferences.
The Content Filtering functionality remains the same as implemented in the non-CUPS architecture. For more
information, refer to Content Filtering Support Overview chapter in the CF Administration Guide.

Configuring the Content Filtering

Use the following additional configuration to enable the content filtering:
configure
require user-plane content-filtering
content-filtering category database directory path path_address
content-filtering category database max-version version_number
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
264
 Cisco Confidential - Limited Release
L7 PCC Rules
Content Filtering

Note The above configuration must be configured on the User Plane, during boot time, to enable Content Filtering.
Defining the above configuration post the User Plane configuration will lead to errors and inconsistencies.

Note To enable the feature, license for User Plane as well as existing content filtering license is required on Uplane.

Note For ICSR User Plane 1:1, the database is loaded pn both the UP's, separately. The rest of the Content Filtering
configurations on Control Plane remains the same. The Content Filtering configuration is pushed from Control
Plane to active the User Plane and then to standby User Plane.

Configuration on Control Plane

The following sample configuration demonstrates changes required on Control Plane for Content Filtering:
config
active-charging-service ACS
content-filtering category policy-id 1
analyze priority 1 category ABOR
analyze priority 2 category ADVERT action allow
analyze priority 2 category ADVERT action allow action content-insert "Content
Restricted : The Web Guard feature has been enabled on your line. Web Guard has restricted
your access to this content. The person on your Wireless account who is designated as the
Primary Account Holder can disable this restriction through the account management website"

exit
rulebase cisco
content-filtering mode category static-only
content-filtering flow-any-error permit
content-filtering category policy-id 5

The configuration on the Control Plane is pushed to User Plane using the PFD mechanism.
Use the following show commands to validate the content filtering configuration on User Plane:
• show user-plane-service rulebase name cisco
• show user-plane-service content-filtering category policy-id

Use the following show commands to check the CFDB spawning on User Plane:
• show content-filtering category database facility srdbmgr
• show content-filtering category database verbose debug-only
• show content-filtering category database verbose
• show content-filtering category database url
• show content-filtering category url

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
265
 Cisco Confidential - Limited Release
L7 PCC Rules
DNS

The Content Filtering policy ID received from PCRF for a particular subscriber is sent to User Plane during
call establishment. The PFCP messages Sx establishment request/Sx modify request contains the CF Policy
ID.
Use the following command to check the CF Policy Id on User Plane:
show subscribers user-plane-only callid full all
The following filed is displayed in support of Content Filtering in CUPS:
• Content Filtering Policy ID

Use the following show commands to monitor the SRDB Request/Response/CF Polict actions:
• show user-plane-service inline-services content-filtering category statistics
• show user-plane-service inline-services content-filtering category statistics rulebase name
• show content-filtering category statistics
• show content-filtering category statistics facility srdbmgr instance 1
• show content-filtering category statistics volume all

Note All existing bulk statistics defined for Content Filtering in the non-CUPS architecture is also applicable in
CUPS.

Limitations
• Dynamic content filtering mode is not supported.
• Rulebase command content-filtering flow-any-error [ permit | deny ] is not supported.

DNS
Offloading to SM-P
DNS packets are not offloaded to SM-P.

Charging
DNS packets are charged at SM-P.

Rule Matching
The functionality remains the same as the non-CUPS architecture.

Statistics
Use the following CLI command to get statistics related to DNS: show user-plane-service statistics analyzer
name dns

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
266
 Cisco Confidential - Limited Release
L7 PCC Rules
DNS Snooping

DNS Snooping
Charging
The charging of DNS Snooping takes place at SM-P.

Rule Definitions
Use the following CLI commands for specifying the rule definition hostnames (domain-names) and part of
the host names.
ruledef <ruledef_name>
ip [server-domain-name {contains|=|ends-with|starts-with} <url_string>]

ip [server-domain-name {contains|=|ends-with|starts-with} <url_string>]

multi-line-OR enabled
Use the no version of this CLI to delete the ruleline for ip server- domain-name.
ruledef <ruledef_name>
no ip [server-domain-name {contains|=|ends-with|starts-with} <url_string>]

exit
Use the following CLI for configurable timer of DNS entries at ECS level.
configure
active-charging service service_name
ip dns-resolved-entries timeout <value_secs>
end
Whenever the ruledef containing the ip server-domain-name keyword is defined and used in rulebase, the
ip-table is created per rulebase per instance.

Rule Matching
The functionality remains the same as the non-CUPS architecture.

Show CLIs
Use the following CLIs to check the table for DNS IP entries:show user-plane-service [ statistics
dns-learnt-ip-addresses {summary | sessmgr instance <id> |all [ verbose ] } ]

Bulkstats
The following bulkstats are available in support of DNS Snooping feature:
• ecs-dns-learnt-ipv4-entries
• ecs-dns-flushed-ipv4-entries
• ecs-dns-replaced-ipv4-entries
• ecs-dns-overflown-ipv4-entries
• ecs-dns-learnt-ipv6-entries

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
267
 Cisco Confidential - Limited Release
L7 PCC Rules
FTP

• ecs-dns-flushed-ipv6-entries
• ecs-dns-replaced-ipv6-entries
• ecs-dns-overflown-ipv6-entries

The above bulkstats are added in the ECS schema same as in the non-CUPS architecture.

Note The SNMP Trap generation commands are not supported in CUPS DNS snooping feature.

FTP
Offloading to SM-P
Only for FTP data, TRM is engaged. FTP data flows are eligible for offloading to SM-P.
There is no TRM engagement for control FTP flows.

Charging
FTP packets are charged at SM-P.

Rule Matching
The functionality remains the same as the non-CUPS architecture.

Statistics
Use the following CLI command to get statistics related to FTP: show user-plane-service statistics analyzer
name ftp

HTTP
HTTP Offloading to SM-P
On a header completion of HTTP Request/Response, the uplink/downlink data packets are offloaded to VPP
in the following cases:
• Content-Length – Volume-based offloading is supported for methods like GET and POST. The HTTP
flow with chunk-encoding data transfer mechanism does not get offloaded irrespective of the method
defined in HTTP. If the stream is offloaded based on content-length, then the stream on the other end
will also get offloaded until the former is not onloaded.
• CONNECT Method—The method where both uplink and downlink streams are offloaded after flow is
upgraded to CONNECT.
• WebSocket Method—After the flow is classified as WebSocket protocol, both uplink and downlink
streams are offloaded.
• The streams are onloaded back to SM-U application in either of the following cases:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
268
 Cisco Confidential - Limited Release
L7 PCC Rules
HTTP

• FIN packet received.

• Content-length is breached.
• PDN update.

Header Parsing
Similar to non-CUPS implementation, only the header fields defined in ruledefs, which are included in rulebase,
are parsed. Or, in case of features like x-header, redirection is configured which have dependencies on some
of the HTTP header fields.

Rule Matching
There is no functional change in the way rule-matching takes place in CUPS. The only change is specific to
TRM wherein both uplink and downlink has its own TRM.

HTTP Charging
• Complete Packets are charged at SM-P.
• Partial Packets are charged on SM-U on completion. Packet completing the Partial Packet is also charged
on SM-U.
• Concatenated Packets are charged on SM-U.
• Delay Charging is enabled – In case there are uncharged bytes, the packet along with the uncharged bytes
gets charged on SM-U.
• Response-based charging is enabled – On receiving a Response, both uplink and downlink packets are
charged on SM-U. Subsequent uplink and downlink packets are charged at SM-P, unless they are
partial/concatenated.

X-Header Parsing and Rule-Matching

Ruledefs with x-header rule-lines are parsed and matched.

WebSocket
The functionality remains the same as non-CUPS architecture.

TRM and Response-Based Charging

Transactional Rule Matching will only avoid per-packet rule matching after a flow is fully classified.
Direction-based TRM has been introduced in CUPS, wherein there are two TRMs for a flow, one for uplink
and the other for downlink direction. After a packet enables TRM, subsequent packets (TRM eligible) continue
to match the same rule resulting in efficient rule-matching. That is, uplink packets match the uplink TRM
cached rule, and downlink packets match the downlink TRM cached rule.

URL-Based Redirection
The functionality remains the same as non-CUPS architecture.
For flow action redirect-url, encrypt is not supported. Currently, the following dynamic fields are supported:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
269
 Cisco Confidential - Limited Release
L7 PCC Rules
HTTP

• #HTTP.URI#
• #HTTP.HOST#
• #HTTP.URL#
• #ACSMGR_BEARER_CALLED_STATION_ID#
• #RULEBASE#
• #RTSP.URI#

X-Header Insertion
X-header Insertion is supported in HTTP Requests. The behavior remains same as that of non-CUPS
architecture. With respect to offloading to SM-P:
• Flows, for which X-header is inserted in a packet, are not offloaded.
• With X-header configuration, all TCP OOO packets irrespective of transmit order CLI, will be buffered
and sent out after reordering.

X-Header insertion statistics CLI

show user-plane-service statistics charging-action name charging_action_name
The following fields are added in support of X-header insertion:
• For Request:
• XHeader Bytes Injected
• XHeader Pkts Injected
• XHeader Bytes Removed
• XHeader Pkts Removed
• IP Frags consumed by XHeader

Limitation
• X-Header Spoofing is not supported.
• X-Header Insertion in Response packet is not supported.
• X-Header Encryption with RSA and RC4MD5 is supported but not supported with AES.
• Monitor protocol for X-Header is not supported.
• Following X-Header fields insertion is not supported in a packet: QoS, UIDH, Customer ID, Hash Value,
Time of the Day, Radius String, Session-Id, Congestion Level, User-Profile.

HTTP Analyzer Statistics

Use the following CLI command to get statistics related to the HTTP analyzer: show user-plane-service
statistics analyzer name http

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
270
 Cisco Confidential - Limited Release
L7 PCC Rules
HTTPS

HTTPS
HTTPS Offloading to SM-P
HTTPS flows are offloaded to SM-P after receiving the application packet. With the P2P analyzer, offloading
works when P2P analyzer detects the L7 protocol.

HTTPS Charging
Charging for HTTPS packets are done at SM-P.

Statistics
Use the following CLI command to get statistics related to HTTPS: show user-plane-service statistics
analyzer name secure-http

HTTP URL Filtering

The HTTP URL Filtering feature simplifies rule definitions used for URL detection.
The HTTP request packet can have a proxy (prefixed) URL and an actual URL. If a proxy URL is found in
the HTTP request packet, the HTTP URL Filtering feature truncates this URL from the parsed information
and only the actual URL is used for rule matching and Event Data Records (EDR) generation.

Configuring the HTTP URL Filtering Feature

This section describes how to configure the HTTP URL Filtering feature.

Configuring Group of Prefixed URLs

To configure the group of prefixed URLs, use the following CLI commands:
configure
active-charging service ecs_service_name
group-of-prefixed-urls prefixed_urls_group_name
end

Configuring URLs in the Group of Prefixed URLs

To configure URLs to be filtered in the group of prefixed URLs, use the following CLI commands:
configure
active-charging service ecs_service_name
group-of-prefixed-urls prefixed_urls_group_name
prefixed-url url_1
...
prefixed-url url_10
end

Enabling the Group of Prefixed URLs in Rulebase

To enable the group of prefixed URLs in rulebase for processing prefixed URLs, use the following CLI
commands:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
271
 Cisco Confidential - Limited Release
L7 PCC Rules
HTTP URL Filtering

configure
active-charging service ecs_service_name
rulebase rulebase_name
url-preprocessing bypass group-of-prefixed-urls
prefixed_urls_group_name_1
...
url-preprocessing bypass group-of-prefixed-urls
prefixed_urls_group_name_64
end
This configuration on the control plane chassis will be pushed to the user plane with a PFD message for
“group-of-prefixed-urls” and “rulebase-url-preprocessing”separately.
The group of prefixed URLs has the list of proxy URLs, which must be truncated. The rulebase contains
multiple group of prefixed urls, which must be filtered. Charging ruledefs contain rules for actual URLs that
must be searched after truncating URLs in the group of prefixed URLs.

Note • Each group of prefixed URLs can have a maximum of ten prefixed URLs.
• A maximum of 64 group of prefixed URLs can be created and configured.

Show Commands
show user-plane-service group-of-prefixed-urls all | name group_name
This show command can be used on the user plane to verify whether the group of prefixed URLs are pushed
or not. The output of this command is as follows:
• Name of the group of prefixed URLs
• Prefixed URLs
• Total number of prefixed URLs found

show user-plane-service rulebase name rbase_name

This show command can be used on the user plane to check whether the group of prefixed URLs is configured
in rulebase or not. The output of this command is as follows:
• Name of rulebase
• Name of the groups of prefixed Urls for URL pre-processing

show user-plane-service statistics analyzer name http

The output of this command is as follows:
• Total HTTP Sessions
• Current HTTP Sessions
• Total Uplink Bytes
• Total Downlink Bytes
• Total Uplink Pkts

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
272
 Cisco Confidential - Limited Release
L7 PCC Rules
HTTP URL Filtering

• Total Downlink Pkts

• Uplink Bytes Retrans
• Downlink Bytes Retrans
• Uplink Pkts Retrans
• Downlink Pkts Retrans
• Total Request Succeed
• Total Request Failed
• GET Requests
• POST Requests
• CONNECT Requests
• PUT requests
• HEAD requests
• Websocket Flows
• Invalid packets
• Wrong FSM packets
• Unknown request method
• Pipeline overflow requests
• Corrupt request packets
• Corrupt response packets
• Unhandled request packets
• Unhandled response packets
• Partial HTTP Header Anomaly prevented
• New requests on closed connection
• Memory allocation failures
• Packets after permanent failure
• Prefixed Urls Bypassed
• FastPath Statistics
• Total FP Flows
• Uplink (Total FP Pkts)
• Downlink (Total FP Pkts)
• Uplink (Total FP Bytes)
• Downlink (Total FP Bytes)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
273
 Cisco Confidential - Limited Release
L7 PCC Rules
RTP/RTSP

Note Prefixed URLs Bypassed counter has been added in http analyzer stats as a performance measurement to show
the number of truncated prefixed URLs.

RTP/RTSP
Offloading to SM-P
RTP, being on UDP Protocol, is offloaded immediately.
RTSP flow is not offloaded. There is no TRM engagement for RTSP flows.

Charging
RTP packets are charged at SM-P. RTSP packets are charged at SM-P unless the packets being partial or if
delay-charging is enabled.

Rule Matching
The functionality remains the same as the non-CUPS architecture.

Statistics
Use the following CLI command to get statistics related to RTP: show user-plane-service statistics analyzer
name rtp
Use the following CLI commands to get statistics related to RTSP:
• show user-plane-service statistics analyzer name rtsp
• show user-plane-service statistics analyzer name rtsp verbose

RTP Dynamic Flow Detection

"RTP dynamic-flow-detection" CLI under rulebase, enables the Real Time Streaming Protocol (RTSP) and
Session Description Protocol (SDP) analyzers to detect the child RTP and RTCP flows. If you configure the
RTSP/SIP and SDP analyzers, and RTP dynamic-flow-detection CLI is present, no need to configure explicit
analyzer configuration for RTP/RTCP. With this CLI, the child RTP or RTCP flows get corelated to their
parent RTSP/SIP-SDP flows.
Once the parent flow (RTSP/SIP-SDP) gets cleared, the child RTP/RTCP flows also gets cleared. In the
absence of this CLI, the L7 layer analysis for RTP and RTCP needs a separate analyzer configuration. There’s
no correlation of RTP/RTCP flows to RTSP/SIP-SDP flow.

Rule-matching for Bearer-specific Filters

Rule Matching
The functionality remains the same as the non-CUPS architecture.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
274
 Cisco Confidential - Limited Release
L7 PCC Rules
SIP

IMSI-based rules are matched as per the subscribers IMSI.

APN-based rules allows you to define rule expressions to match Access Point Name (APN) of the bearer flow.
RAT-Type allows you to define rule expressions to match Radio Access Technology (RAT) in the bearer
flow.

Rule Definitions
Use the following CLI commands to configure the IMSI pool.
configure
active-charging service service_name
imsi-pool pool_name
imsi { imsi_number | range start_imsi to end_imsi }
The imsi-pool can contain either IMSI value or range of IMSI.
Use the following CLI commands to configure rule line under ruledef.
configure
active-charging service service_name
ruledef ruledef_name
bearer 3gpp imsi { = imsi_value } | { range imsi-pool pool_name }
bearer 3gpp apn operator apn_name
bearer 3gpp rat-type operator rat_type
IMSI range can be configured in a rule with the help of IMSI pool.
For more information about the CLI commands, see ACS Ruledef Configuration Mode Commands in the
StarOS Command Line Interface Reference.

Show CLIs
Use the following CLI on User Plane to see information about IMSI pool that is configured in a service:show
user-plane-service imsipool name pool_name

SIP
Offloading to SM-P
SIP flow is not offloaded.

Charging
SIP packets are charged at SM-P.

Rule Matching
The functionality remains the same as the non-CUPS architecture.

Statistics
Use the following CLI command to get statistics related to SIP: show user-plane-service statistics analyzer
name sip

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
275
 Cisco Confidential - Limited Release
L7 PCC Rules
SIP

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
276
 Cisco Confidential - Limited Release

CHAPTER 38
Local Policy in CUPS
• Revision History, on page 277
• Feature Description, on page 277
• How It Works, on page 278
• Configuring Local Policy in CUPS, on page 278

Revision History
Revision Details Release

First introduced. 21.9 (5/4/2018)

This Local Policy in CUPS feature is not fully qualified in this release.

Feature Description
The local policies are used to control different aspects of a sessions such as - QoS, Data Usage, Subscription
profiles, Server Usage, and so on, by means of locally defined policies. It is intended as a replacement or
enhancement to PCRF-based policy control. The local policies are triggered during certain events and the
associated conditions.
The Local Policy functionality has the following advantages:
• Reusability: Reusable rules engine as a common infrastructure for PCRF-based policies.
• Resource Consumption: Lower memory usage, CPU usage and response time.
• Extensibility: Extensible to handle new events and attributes with minimal effort.
• Execution speed: Shorter reaction time for network events.
• Integration: Seamless integration with the existing policy infrastructure - IMSA and PCEF with a minimal
impact on existing services. In case of unreachable events, a mechanism to fallback to PCRF is
implemented.

Local policies are useful in various scenarios. For example:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
277
 Cisco Confidential - Limited Release
Local Policy in CUPS
How It Works

• A Local Policy operates as a fallback mechanism when PCRF is unavailable or when an operator has
not deployed PCRF in the infrastructure.
• As an enhancer to PCRF triggers, handling certain triggers locally or to handle triggers unsupported by
3GPP Standards or PCRF.
• Deployments where the subscription policies are static and tiered or has well defined subscriber groups.
• When the response time required is less.

Note The working of the Local Policy feature in the CUPS environment is similar to the non-CUPS P-GW and
SAEGW nodes.

How It Works
Local Policy feature is implemented based on the following concepts:
• Event driven rules engine. For example, RAT change event.
• On a registered Event Trigger occurrence, series of registered rules are evaluated based on the Type of
Event and the current State.
• On a successful rule match, series of actions are executed.

Configuring Local Policy in CUPS

Note The CLI commands available for non-CUPS Local Policy feature are also applicable in CUPS environment.

Following is a sample Local Policy configuration in Control Plane node:

configure
local-policy-service service_name
ruledef ruledef_name
condition priority priority radio-access-technology eq eutran
ruledef ruledef_name
condition priority priority apn eqcompare_string
actiondef actiondef_name
action priority priority default-qos qci qci_value arp arp_value
actiondef actiondef_name
action priority priority activate-rulebase name rulebase_name eventbase
eventbase_name
rule priority priority event new-call ruledef ruledef_name actiondef
actiondef_name
rule priority priority event location-change ruledef ruledef_name
actiondef actiondef_name
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
278
 Cisco Confidential - Limited Release
Local Policy in CUPS
Configuring Local Policy in CUPS

Note No configuration is required in User Plane node.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
279
 Cisco Confidential - Limited Release
Local Policy in CUPS
Configuring Local Policy in CUPS

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
280
 Cisco Confidential - Limited Release

CHAPTER 39
Load/Overload and UP Data Throttling Support
on Sx
• Feature Description, on page 281
• How It Works, on page 281
• Configuring Load and Overload Support, on page 283
• Monitoring and Troubleshooting, on page 287

Feature Description
The Load/Overload support is implemented in the UPC CUPS architecture. This support is handled between
the Contol Plane (CP) and User Plane (UP).
Load control enables UP to send its load information to CP to adaptively balance the PFCP session load across
the UP functions according to their effective load, whereas Overload control enables throttling of new session
requests towards a particular UP.

How It Works
User Plane Selection
When Load/Overload support is enabled, UP selection is implemented as given below, with a UP group:
• If none of the UP is in overload condition, Load Control Information (LCI) is used for UP selection. In
this case, the least loaded UP will be selected.
• If all UPs are in the overload state, UP selection is based on the Overload Control Information (OCI). In
this case the least overloaded UP is selected.
• After a particular UP is selected, the reduction metric is still applied to this UP for throttling.
• If throttling needs to be dropped, UP selection request is rejected for that PDN connection.

• In some scenarios where some of the UPs are in Overload condition and some of the UPs are not in
Overload condition, the selection is done based on the OCI value.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
281
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
Node-level Load/Overload Support

• If the LCI or the OCI value are the same for a peer node, the session count information is used for UP
selection.

Node-level Load/Overload Support

The CP informs the UP about the Load/Overload support enabled. Based on this information UP decides to
send the Load/Overload information towards CP peer or not.
Load/Overload support at CP is configured as part of the Sx-Service node configuration. This information is
sent to the UP during Sx Association Response or Sx Association Update request, if the information has
changed through dynamix configuration.

Note If CP does not support Load/Overload feature through supported CLI, it ignores the reported Load/Overloadby
UP. In that case, UP selection continues with the session count information.

Sx Establishment Request Throttling at CP in Overload State

Once the UP is in Overload situation, CP starts throttling the Sx Establishment Request message towards UP.
This avoids new calls (Low priority/non-emergency) towards the overloaded UP.
Throttling happens based on reported OCI values – Overload Reduction metric value. The value is calculated
in percentage. It randomly drops the required percentage of Sx Establishment Request towards that UP Peer.
This results in call drop at CP with "sx-no-resource" disconnect reason. Also, respective statistics are
incremented for the same.

Note The eMPS (high priority) subscribers' Session/ Emergency Subscribers' session is not throttled.

Sx Establishment Request Throttling at UP in Self-Protection

Once the UP is in Self-Protection state, it starts rejecting all the new sessions (non-eMPS session only), Sx
Establishment Request, and Sx Modification Request for the existing sessions (non-eMPS session only).

Session Termination Trigger from UP in Self-Protection

Being in Self-Protection mode, if there are no improvement in the Load condition at UP, it starts triggering
Session Termination Request towards CP in a staggered manner through Sx Report Request message indicating
that UP is in Self-Protection. Based on this, CP starts initiating Sx Termination Request for those sessions.
Self Protection Termination Request (SPTER): This bit is set from UP towards CP for initiating Self-Protection
based termination. The CP releases the call with disconnect reason as "graceful-term-up-self-protectn".

Note When Actual Load value is greater than the Session-Termination-Start-Threshold value, Session termination
is triggered towards CP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
282
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
Limitation

Limitation
This feature has the following limitations:
• The maximum number of Load/Overload profiles supported on UP is 8.
• If the Load/Overload profiles are not configured in all UPs in the UP group, it can lead to uneven
distribution of sessions. It is recommended that all UPs must be configured with the Load/Overload
support in a single UP group.
• After session recovery, SessMgr instance gets to relearn Load/Overload values from SxDemux. The
SxDemux communicates these values only when there is a change in Load/Overload values.

Configuring Load and Overload Support

The Load and Overload support is configured using the following configurations:
• User Plane Load Control Profile Configuration
• User Plane Overload Control Profile Configuration
• Association of Load Profile to a User Plane Service
• Sx Protocol Configuration on Control Plane

User Plane Load Control Profile Configuration

Use the following commands to configure load control profile.
configure
userplane-load-control-profile profile_name
end

Configuring User Plane Load Control Profile Parameters

Use the following configuration to configure UP Load profile parameters:
configure
userplane-load-control-profile profile_name
system-weightage system-cpu-utilization utilization_value
system-memory-utilization utilization_value license-session-utilization
utilization_value
sessmgr-weightage sessmgr-cpu-utilization utilization_value
system-memory-utilization utilization_value
inclusion-frequency advertisement-interval interval_value change-factor
changefactor_value
end
NOTES:
• inclusion-frequency: Configures parameters to decide inclusion frequency of load control information
IE.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
283
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
User Plane Overload Control Profile Configuration

• advertisement-interval: Configures the advertisement interval for load control. The default value is
300. Set the value as 0 (zero) to include LCI IE in every applicable message.
• change-factor: Configures the change factor for load control. The default value is 5.
• sessmgr-weightage: Configures sessmgr weightage for various load control parameters. Total weightage
of all the parameters should be 100. The default ratio is 65% weightage to sessmgr-cpu-utilization and
35% weightage to sessmgr-memory-utilization.
• sessmgr-cpu-utilization: Configures session manager CPU utilization weightage in percentage. Default
weightage in load factor is 35%.
• sessmgr-memory-utilization: Configures session manager memory utilization weightage in percentage.
Default weightage in load factor is 65%.
• system-weightage: Configures system weightage for various load control parameters. Total weightage
of all the parameters should be 100. The default values are 40% weightage to system-cpu-utilization,
30% weightage to system-memory-utilization and 30% weightage to license-session-utilization.
• system-cpu-utilization: Configures system CPU utilization weightage in percentage. Default weightage
in load factor is 40%.
• system-memory-utilization: Configures system memory utilization weightage in percentage. Default
weightage in load factor is 30%.
• license-session-utilization: Configures license session utilization weightage for User Plane service in
percentage. Default weightage in load factor is 30%.

User Plane Overload Control Profile Configuration

Use the following commands to configure overload control profile.
configure
userplane-overload-control-profile profile_name
end

Configuring User Plane overload Control Profile Parameters

Use the following configuration to configure UP overload profile parameters:
configure
userplane-overload-control-profile profile_name
overload-threshold system lower-limit limit_value upper-limit limit_value
sessmgr lower-limit limit_value upper-limit limit_value vpp-cpu lower-limit
limit_value upper-limit limit_value
system-weightage system-cpu-utilization utilization_value
system-memory-utilization utilization_value license-session-utilization
utilization_value
sessmgr-weightage sessmgr-cpu-utilization utilization_value
system-memory-utilization utilization_value
inclusion-frequency advertisement-interval interval_value change-factor
changefactor_value
tolerance tolerance_value
validity-period validity_period
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
284
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
User Plane Overload Control Profile Configuration

NOTES:
• inclusion-frequency: Configures parameters to decide inclusion frequency of overload control information
IE.
• advertisement-interval: Configures the advertisement interval for load control. The default value is
300. Set the value as 0 (zero) to include LCI IE in every applicable message.
• change-factor: Configures the change factor for load control. The default value is 5.
• tolerance: Configures the Overload tolerance limits.
• validity-period: Configures validity of overload control information. Default value is 600.
• overload-threshold: Configures Overload thresholds limits for system, sessmgr and vpp-cpu.
• system: Configures overload system threshold after which node moves to self-protection mode.
• vpp-cpu: Configures the overload vpp-cpu threshold after which node moves to self-protection mode.
• sessmgr: Configures the overload threshold for session manager after which node moves to self-protection
mode.
• upper-limit limit_value: Configures the various upper limit values. Following are the various upper limit
values:
• System Threshold Upper Limit : Configures overload system threshold after which node moves to
self-protection mode. Default limit value is 80%.
• Sessmgr Threshold Upper Limit : Configures overload SessMgr threshold after which node moves
to self-protection mode. Default limit value is 60%.
• vpp-cpu Threshold Upper Limit : Configures overload vpp-cpu threshold L2 after which node moves
to self-protection mode. Default limit value is 60%.

• lower-limit limit_value: Configures the various lower limit values. Following are the various lower limit
values:
• System Threshold Lower Limit: Configures overload system threshold after which node moves to
self-protection mode. Default limit value is 60%.
• Sessmgr Threshold Lower Limit: Configures overload SessMgr threshold after which node moves
to self-protection mode. Default limit value is 50%.
• vpp-cpu Threshold Lower Limit : Configures overload vpp-cpu threshold L1 after which node
moves to self-protection mode. Default limit value is 50%.

• sessmgr-weightage: Configures sessmgr weightage for various overload control parameters. Total
weightage of all the parameters should be 100. The default ratio is 65% weightage to
sessmgr-cpu-utilization and 35% weightage to sessmgr-memory-utilization.
• sessmgr-cpu-utilization: Configures session manager CPU utilization weightage in percentage. Default
weightage in overload factor is 35%.
• sessmgr-memory-utilization: Configures session manager memory utilization weightage in percentage.
Default weightage in overload factor is 65%.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
285
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
Associating a Load Control Profile with a User Plane Service

• system-weightage: Configures system weightage for various overload control parameters. Total weightage
of all the parameters should be 100. The default values are 40% weightage to system-cpu-utilization,
30% weightage to system-memory-utilization and 30% weightage to license-session-utilization.
• system-cpu-utilization: Configures system CPU utilization weightage in percentage. Default weightage
in overload factor is 40%.
• system-memory-utilization: Configures system memory utilization weightage in percentage. Default
weightage in overload factor is 30%.
• license-session-utilization: Configures license session utilization weightage for User Plane service in
percentage. Default weightage in overload factor is 30%.

Associating a Load Control Profile with a User Plane Service

Use the following commands to associate the Overload Control profile to a use plane service.
configure
context context_name
user-plane-service service_name
[ no ] associate userplane-load-control-profile profile_name

NOTES:
• associate: This command associates the user plane overload control profile with a user plane service.

Sx Protocol Configuration on Control Plane

The CP Function Features IE indicates the features supported by CP. Only features having an impact on the
(system-wide) UP function behaviour are signalled in this IE.
The following features are supported by CP:
• LOAD (Load Control)
• OVRL (Overload Control)

Use the following configuration to configure the supported features on CP through the Sx Protocol:
configure
context context_name
sx-service service_name
sx-protocol supported-features { load-control | overload-control
}
no sx-protocol supported-features [ load-control | overload-control
]
end
NOTES:
• supported-features: Configures supported features for Sx interface by CP. Default value is Disabled.
• load-control: Enables or disables Load control feature support on CP function.
• overload-control: Enables or disables the Overload control feature on CP function.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
286
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
Monitoring and Troubleshooting

Monitoring and Troubleshooting

Show Commands Input and/or Outputs
This section provides information regarding show commands and their outputs in support of the feature.

show userplane-load-control-profile name name

The following fields are displayed in support of this feature:
• User Plane Load Control Profiles
• User Plane Load Control Profile Name
• System Weightage and Thresholds:
• CPU Utilization Weightage
• Memory Utilization Weightage
• License Session Utilization Weightage
• System Threshold Lower Limit
• System Threshold Upper Limit

• Sessmgr Weightage and Thresholds:

• CPU Utilization Weightage
• Memory Utilization Weightage
• Sessmgr Threshold Lower Limit
• Sessmgr Threshold Upper Limit

• VPP Weightage and Thresholds:

• VPP Utilization Weightage
• vpp-cpu Threshold Lower Limit
• vpp-cpu Threshold Upper Limit

• Inclusion Frequency:
• Change Factor
• Advertisement Interval

show userplane-overload-control-profile name name

The following fields are displayed in support of this feature:
• User Plane Overload Control Profiles

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
287
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
show user-plane-service statistics all

• User Plane Overload Control Profile Name

• System Weightage and Thresholds:
• CPU Utilization Weightage
• Memory Utilization Weightage
• License Session Utilization Weightage
• System Threshold Lower Limit
• System Threshold Upper Limit

• Sessmgr Weightage and Thresholds:

• CPU Utilization Weightage
• Memory Utilization Weightage
• Sessmgr Threshold Lower Limit
• Sessmgr Threshold Upper Limit

• VPP Weightage and Thresholds:

• VPP Utilization Weightage
• vpp-cpu Threshold Lower Limit
• vpp-cpu Threshold Upper Limit

• Inclusion Frequency
• Change Factor
• Advertisement Interval

• Validity Period

show user-plane-service statistics all

The following fields are displayed in support of this feature:
• Overload Stats
• Current State : Normal
• Number of time self-protection condition reached in user plane : 0
• No of Session Eshtablishment Req rejected during self-protection mode : 0
• No of Session Modif Req rejected during self-protection mode : 0
• No of eMPS Session Eshtablishment Req allowed during self-protection mode : 0
• No of eMPS Session Modif Req allowed during self-protection mode : 0
• Overload reduction metric : 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
288
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
show sx service statistics all

• Current Overload factor system : 0

• Current Overload factor sessmgr : 0
• Current Overload factor vpp cpu : 0

• Overload Data Stats:

• Total Packets dropped due to overload : 0
• Total Bytes dropped due to overload : 0
• Total Packets dropped in self-protection mode : 0
• Total Bytes dropped in self-protection mode : 0

• Load Stats:
• Load metric : 0
• Current Load factor system : 0
• Current Load factor sessmgr : 0
• Current Load factor vpp cpu : 0

• eMPS PDNs Total

• Active
• Setup
• Released
• Rejected

show sx service statistics all

The following fields are displayed in support of this feature:
• Throttled

Bulk Statistics
Following bulkstats are available in support of Load and Overload Support on Sx feature.

Table 13: Supported Bulk Stats

Bulkstats Description

num-self-protection-reached Total number of time self-protection condition reached

in UP.

num-session-estab-rejected-on-self-protection Total number of Session Establishment Request

rejected during self-protection mode.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
289
 Cisco Confidential - Limited Release
Load/Overload and UP Data Throttling Support on Sx
SNMP Traps

Bulkstats Description

num-session-modif-rejected-on-self-protection Total number of Session Modification Request

rejected during self-protection mode.

num-emps-session-estab-allowed-on-self-protection Total number of eMPS Session Establishment Request

allowed during self-protection mode.

num-emps-session-modif-allowed-on-self-protection Total number of eMPS Session Modification Request

allowed during self-protection mode.

overload-reduction-metric Overload reduction metric is calculated based on the

configured Lower and Upper limit of Overload
Condition.

overload-factor-system Overload factor system is calculated based on the

System CPU, Memory, VPP CPU, and other
information polled from Resource Manager (RM).

overload-factor-session UP starts rejecting new sessions and data throttling

during self-protection mode.

overload-factor-vpp-cpu Total average VPP CPU per core during overload.

load-metric Total number of current Load metric.

load-factor-system Total number of current sytem load factor.

load-factor-session Total number of current session load factor.

load-factor-vpp-cpu Total number of current VPP CPU load factor.

num-packets-dropped-on-overload Total number of packets dropped during the overload.

num-bytes-dropped-on-overload Total number of bytes dropped during the self

protection mode.

num-packets-dropped-on-self-protection Total number of packets dropped during the self

protection mode.

num-bytes-dropped-on-self-protection Total number of bytes dropped during the self

protection mode.

SNMP Traps
The following SNMP Traps are added in support of this feature:
• UPlaneSelfOverload: When system enters into Self-Protection mode.
• UPlaneSelfOverloadClear: When system is out of Self-Protection mode.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
290
 Cisco Confidential - Limited Release

CHAPTER 40
LTE - Wi-Fi Seamless Handover in CUPS
• Revision History, on page 291
• Feature Description, on page 291
• How It Works, on page 292
• Configuring LTE and Wi-Fi Seamless Handover, on page 293
• Monitoring and Troubleshooting, on page 294

Revision History
Revision Details Release

Error and Collision scenarios are supported. 21.15.1

First introduced. 21.15.M0

This feature is not fully qualified in this release.

Feature Description
Seamless handovers between LTE and Wi-Fi (S2a/S2b), for UEs that need continuity with their ongoing data
session, is supported in the CUPS architecture.
When handover is initiated from LTE to Wi-Fi, the Delete Bearer Request (DBR) is sent over the LTE tunnel
immediately when the Create Session Response (CSR) is sent on the Wi-Fi tunnel. This causes some packet
loss because of the IPSec tunnel establishment delay at the ePDG. To address the issue of packet loss, a Delete
Bearer Request is sent on LTE tunnel only on expiry of the configured handover timer. If the LTE tunnel is
active, uplink and downlink data are exchanged on the LTE tunnel. When handover is complete, uplink and
downlink data is exchanged on the Wi-Fi tunnel. This prevents packet loss. During Wi-Fi to LTE handover,
if the Modify Bearer Request is received with HI=1, it initiates a tunnel switch from Wi-Fi to LTE as per the
specification.
With this feature, the following benefits are seen:
• Minimum packet loss during LTE to Wi-Fi (S2bGTP) handover and making the handover seamless (that
is, MAKE before BREAK).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
291
 Cisco Confidential - Limited Release
LTE - Wi-Fi Seamless Handover in CUPS
How It Works

• LTE procedures are handled gracefully over the LTE tunnel when both tunnels are established with the
P-GW.
• Wi-Fi procedures are handled gracefully over the Wi-Fi tunnel when both tunnels are established with
the P-GW.

Important • In an LTE to Wi-Fi or Wi-Fi to LTE handover, a tunnel identifier is allocated for new access traffic type
for experiencing seamless handover.

How It Works
LTE - Wi-Fi Handover
• Before HO is started:
• In case of multiple outstanding CCR-Us being supported, all requests before the hand-off requests
are dropped.
• Any pending transactions on LTE access are discarded. For example, if CBR or UBR is sent for
LTE access and hand-off is initiated before completion of CBR or UBR transaction, then CBR or
UBR is ignored at the P-GW. PCRF is not notified about failure.

• During the transition period:

• If PCRF sends RAR for policy change, it is processed after handover is complete.
• If ASR is received, then call drop occurs and both tunnels go down.
• If session-release occurs from PCRF, then call is dropped and CSR is sent with cause as
“no-resources”.
• If the user moves back to LTE (that is, recurring handoff from LTE to Wi-Fi to LTE) with HO-Ind
set to 1 (after guard timer), then the HO is processed successfully and user session is moved to LTE
again.
• If the user moves back to LTE (that is, recurring handoff from LTE to Wi-Fi to LTE) with HO-Ind
set to 0, then it leads to context replacement. Old call is cleared on Wi-Fi access with the reason
"Context Replacement", and the call is processed like a new call over LTE.
• If Modify Bearer Command (MBC) is received in LTE (New access), it is rejected with
Service-Denied message.
• If Modify Bearer Command (MBC) is received in Wi-Fi (Old access), it is discarded.
• If Delete Bearer Command (DBC) is received in LTE (New access) during the HO in progress,
session is terminated.
• In case of Sx Path Failure during an ongoing handover, on-going transactions are aborted, resulting
in tearing down the call locally.
• GTPC S5/S11 path failure

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
292
 Cisco Confidential - Limited Release
LTE - Wi-Fi Seamless Handover in CUPS
ICSR and Session Recovery

• During LTE to Wi-Fi HO, if path failure occurs on an older tunnel, then the call is cleared. If
path failure occurs on a newer tunnel, it result in tearing the call .
• During the Wi-Fi to LTE HO, when path failure happens on an older tunnel, the older tunnel
is cleared and the new tunnel call continues. This is possible only if the MBReq is pending
from MME. In all other states, the call is teared down locally.
• WIFI to LTE (Collapsed call) HO, call continuation is not possible. Path failure on an older
tunnel only results in tearing down the call locally.
• During the HO, if path failure occurs on a Newer tunnel, it will result in tearing down the call.

ICSR and Session Recovery

• At Control Plane, during transition, the most recent is considered as the stable state and a full checkpoint
is triggered once handover is complete from LTE to Wi-Fi (S2BGTP) or vice-versa. This is applicable
to Session Recovery and ICSR. User Plane has individual session recovery and ICSR check pointing on
every message received.
• During handover failure, that is, when CP and UP are out of sync, the CP session is recovered on the
most recently accessed state and UP is recovered in the new transition state. This behavior is applicable
during UP failure.

Limitations
The LTE - Wi-Fi Seamless Handover feature does not support LTE to eHRPD and Wi-Fi to eHRPD handover
and hand back.

Standards Compliance
The LTE – Wi-Fi Seamless Handover feature is compliant with the following standards:
• 3GPP TS 23.214
• 3GPP TS 29.244
• 3GPP TS 23.401
• 3GPP TS 23.402

Configuring LTE and Wi-Fi Seamless Handover

The following section provides information about the CLI commands available to enable or disable the feature.
Use the following CLI commands to configure LTE to Wi-Fi handover timer.
configure
context context_name
apn apn_name
lte-s2bgtp-first-uplink timeout_value

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
293
 Cisco Confidential - Limited Release
LTE - Wi-Fi Seamless Handover in CUPS
Monitoring and Troubleshooting

{ default | no } lte-s2bgtp-first-uplink
end
NOTES:
• default: Enables the LTE to Wi-Fi handover completion to occur when the Create Session Response is
sent on the Wi-Fi tunnel.
• no: Disables the feature and handover completion occurs on Create Session Response.
• lte-s2bgtp-first-uplink timeout_value: Configures LTE to S2bGTP handover completion timeout in
multiples of 100 milliseconds. The valid range is from 100 to 3000. The recommended configuration is
1000 milliseconds.
• By default, the LTE to Wi-Fi handover completion happens when Create Session Response is sent on
the Wi-Fi tunnel. However, after handover timeout is configured, the handover is delayed until timeout.
• Triggering handover based on first uplink data packet is not supported because the User Plane and Control
Plane nodes are separated in the CUPS architecture.

Monitoring and Troubleshooting

This section provides information regarding CLI commands available in support of monitoring and
troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show apn statistics name <name>

The output of this CLI command has been enhanced to display the following new fields for the APN:
• LTE-to-S2bGTP handover Succeeded on Timer Expiry – Specifies the number of handovers due to timer
expiry.

NOTES:
The new fields, introduced as part of this feature, are also displayed for the following CLI commands:
• show pgw-service statistics name service_name verbose
• show pgw-service statistics name all verbose
• show saegw-service statistics all function pgw verbose

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
294
 Cisco Confidential - Limited Release

CHAPTER 41
Monitor Subscriber for CUPS
• Revision History, on page 295
• Feature Description, on page 295
• Monitor Subscriber Sx Private IE, on page 297
• Control Plane SMGR Functionality, on page 301
• User Plane SMGR Functionality, on page 301
• Multi PDN Multi Trace, on page 302
• MonSub Stats, on page 303
• X-Header, on page 303
• How It Works, on page 303
• Configuring the Hexdump Module for MonSub in CUPS, on page 311
• Monitoring and Troubleshooting, on page 313

Revision History
Revision Details Release

In this release, enhancement related to MonSub CLI, subscriber tracing 21.22.x

limits, packet processing throughput, PCAP success and, error code
notifications are added to this feature. The CP and UP SMGR functionality
is also added for this release.

First introduced. 21.16.1

Feature Description
The Monitor Subscriber (MonSub) feature enables tracing of subscriber related information which includes
user and control traffic, and events such as charging and internal events that are useful for debugging. By
default, this information is displayed on the Control Plane console, where the user executes MonSub tracing
CLI command and captured in a Packet Capture (PCAP) file on the User Plane.
User traffic is carried on slowpath where packets traverse to the application or fastpath where packets do not
have to traverse up to the application but are offloaded to fastpath processing (VPP). Slowpath mode was the
default mode until fastpath offload (VPP) into SAEGW, was introduced.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
295
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Feature Description

Monitor Subscriber provides the following functionality:

• Continuous capture of user traffic from fastpath in PCAP files on the User Plane.
• The non-user traffic information, that is, control event traffic and other related information are displayed
in Control Plane console and are captured in separate PCAP files on the User Plane.
• New option UP PCAP trace [W - UP PCAP Trace (ON)] is introduced for CUPS on Control Plane and
User Plane in MonSub CLI. The new option is like the D option in the ICUPS. The slow-path and fast-path
PCAP generates only when this option is ON.
• There are a maximum of four subscriber tracing sessions per NPUMGR instance. The NPUMGR (per
User Plane instance) enforces the maximum tracing session limit. Slow-path capture naming convention
contains the MonSub tracing session ID on SMGR instance, whereas fast-path tracing session contains
the PSN as session ID. If there are already four tracing sessions running at SESSMGR instance, then
slow-path capture is by name “S4”. It continues until the time NPUMGR rejects the tracing session due
to max tracing limit reached.

Following are some of the important definitions related to this feature:

• Chassis Traffic Volume: The total volume of packet throughput on the chassis.
• Monitored Traffic Volume: Monitoring of the total throughput of all the subscribers through MonSub
across all the MonSub sessions.
• PCAP success: The percentage of the MonSub traffic capture request and the successful capture in the
PCAP files.

Packet Processing Throughput

Following are the scenarios that impacts the packet processing throughput:
• When VPP utilization is above 80%, MonSub may have an impact to packet processing throughput. The
impact is in proportion to the monitored traffic volume.
• Specifically, when the monitored traffic volume approaches 10% of the chassis traffic volume, there may
be impact on the VPP throughput causing subscriber packet loss.
• The impact to packet processing throughput is higher when using monitor priorities above 0 (zero).

Caution you must be cautious during the packet processing. When VPP is running at 80%
utilization and handling approximately 10Gbps chassis traffic volume, there’s
impact on the packet processing, if the set of MonSub sessions is collectively
monitoring the subscribers, totaling more than 1Gbps of monitored traffic volume.

PCAP Success
The PCAP success depends on the following factors:
• The level of PCAP success depends on several factors, including monitored traffic volume, VPP utilization,
MonSub monitor priority, and background disk I/O.
• In general, the PCAP success rates are greater for the following cases:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
296
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monitor Subscriber Sx Private IE

• When the VPP utilization is low and/or MonSub monitor priority is above best-effort.
• When the monitored traffic volume is less than 10% of the chassis traffic volume.

Example: When VPP is running at 80% utilization, handling approximately 10Gbps chassis traffic
volume, monitored traffic volume up to 1Gbps is likely to yield high PCAP success percentages.

Monitor Subscriber Sx Private IE

SUBSCRIBER TRACE
The Monitor Subscriber Sx Private IE is conditional IE in the Sx Session Establishment Request and Sx
Session Modification Request. This IE is valid for Sxa, Sxb and Saxb call types only.
Figure 10: Subscriber Tracing

Action: STOP / START monitor subscriber tracing. STOP =1, START =2.

Note D = DATA events tracing is ON if D=1. The 8 octets (d to d+7) contain data events tracing information should
be present only when D=1.
C = CONTROL events tracing is ON if C=1.

Data Tracing Information (8 octets): It will contain the data filter parameters like Packet capture, Packet
capture size, and MEH header.
• Octet 1:
• Bit 1 – VPP enable/disable

• Bit 2 – FCAP - Packet capture

• Bit 3 – MEH present

• Bit 4 to 6 - Priority

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
297
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monitor Subscriber Sx Private IE

• Octet 2 to 3: Packet size

• Octet 4 – 8: Reserved for future use. Currently, all set to 0.

Protocol Tracing Information (16 octets/128 bits): The 16 octets (p to p+15) contain protocol tracing
information and should be present only when either control flag (C) or data flag (D) is enable. Each bit
represents a unique protocol to monitor. Example, If 49th bit is 1, PFCP events tracing is ON. The Protocol
Tracing Rulematch Events (Option 34), L3 Data (Option 19), EDR (Option 77) and Subscriber Summary After
Call Disconnect are controlled by control event flag.

Subscriber Trace Status Report (UP to CP only)

When Subscriber Trace is enabled for a PFCP session, the Report Type IE contains one extra octet (Octet 6).
Presence of this octet is indicated by the length.
Figure 11: Report Type IE

Octet 5 shall be encoded as follows:

• Bit 1 – DLDR (Downlink Data Report): when set to 1, this indicates Downlink Data Report.
• Bit 2 – USAR (Usage Report): when set to 1, this indicates a Usage Report .
• Bit 3 – ERIR (Error Indication Report): when set to 1, this indicates an Error Indication Report.
• Bit 4 – UPIR (User Plane Inactivity Report): when set to 1, this indicates a User Plane Inactivity Report.
• Bit 5–6 Spare.
• Bit 7 – SRIR (Session Replacement): when set to 1, this indicates a Session Replacement request from
UP.
• Bit 8 – GTER (Graceful termination): when set to 1, this indicates a Graceful Termination request from
UP.

Octet 6 (present when Length>1) to be encoded as follows:

• Bit 1 – STS (Subscriber Trace Status Report): when set to 1, this indicates Subscriber Trace Status Report.
• Bit 2 to 8 – Spare.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
298
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monitor Subscriber Sx Private IE

Subscriber Trace Status Report IE (Private IE)

The Subscriber Trace Status Report IE is a conditional IE for only Sxa, Sxb and Sxab call types. For N4 call
type, this IE is not present.
Figure 12: Subscriber Trace Status Report

The status code indicates the acceptance or the rejection of the subscriber trace at UP. Status code = 0 means,
a success. Values 1-255 uniquely specifies the specific error code or notification. The list of error codes are
defined post development.

Table 14: Error Code and Notification Table

Status Code Status Description

MONSUB_SM_SUCCESS (0)
MONSUB_SM_ERROR_FAILURE (1) MonSub : Generic Failure status
received
MONSUB_SM_ERROR_UNSUPPORTED (2) MonSub : Unsupported Failure!
MONSUB_SM_ERROR_SESSION_EXIST_NONE (3) MonSub : Session not Found!" );
MONSUB_SM_ERROR_SESSION_LIMIT_EXCEED (4) MonSub : Max Connections
reached!
MONSUB_SM_ERROR_SESSION_INVALID_PARAM (5) MonSub : Connect Message Failed!
MONSUB_SM_ERROR_SESSION_ALLOC_FAIL (6) MonSub : Could not allocate
monsub sesson at NPU!
MONSUB_SM_ERROR_CONFIG_INVALID_PARAM (7) MonSub : Config Message Failed!
MONSUB_SM_ERROR_MONITOR_LIMIT_EXCEED (8) MonSub : Max Stream Limit
reached!
MONSUB_SM_ERROR_MONITOR_INVALID_PARAM (9) MonSub : Monitor Message Failed!
MONSUB_SM_ERROR_MAX (10) MonSub: Max Error!

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
299
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monitor Subscriber Sx Private IE

Status Code Status Description

MONSUB_COPROCDATA_CORRUPTED (11) MonSub : File Handling Process
Failed!
MONSUB_MAX_TRACING_SESSIONS_REACHED (12) MonSub : Maximum Number of
Tracing Sessions reached!
MONSUB_STOP_RECVD_WAIT_POLL_TIMEOUT (13) MonSub : STOP notification is
Successful. Wait till the poll-timeout
configuration to start the next
tracing!
MONSUB_FILECOPY_SOURCE_DIR_NOT_EXIST (14) MonSub : Source Directory does
not exist!
MONSUB_FILECOPY_DEST_DIR_NOT_EXIST (15) MonSub : Destination Directory
does not exist!
MONSUB_FILECOPY_SOURCE_DIR_OPEN_FAILURE (16) MonSub : unable to open Source
Directory!
MONSUB_FILECOPY_DEST_DIR_OPEN_FAILURE (17) MonSub : Unable to open
Destination Directory!
MONSUB_FILECOPY_SOURCE_OPEN_FAILED (18) MonSub : Unable to open Source
File!
MONSUB_FILECOPY_DESTINATION_OPEN_FAILED (19) MonSub : Unable to open
Destination File!
MONSUB_FILECOPY_DONE_FILE_DELETION_FAILED (20) MonSub : Unable to delete .done
file in Source Path!
MONSUB_FILECOPY_PCAP_FILE_DELETION_FAILED (21) MonSub : Unable to delete .pcap
file in Destination Path!
MONSUB_RESPONSE_NPUMGR_MONSUB_SESS_FAILED (22) MonSub : Messenger Failure during
Session Notification to NPUMGR!
MONSUB_RESPONSE_NPUMGR_MONSUB_CFG_FAILED (23) MonSub-Config push to NPUMGR!
MONSUB_RESPONSE_NPUMGR_MONSUB_MONITOR_FAILED MonSub-Monitor Notification to
(24) NPUMGR!
MONSUB_RESPONSE_COPROC_FAILED (26) MonSub : File Handling Process
Failed!
MONSUB_RESPONSE_FILE_TRANSFER_SUCCESS (27) MonSub: File Transfer successful.
MONSUB_RESPONSE_FILE_TRANSFER_FAILED (28) MonSub: File Transfer failed!
MONSUB_ADMINISTRATIVE_DISCONNECT (29) MonSub: Administrative
Disconnect!
MONSUB_FILECOPY_DESTINATION_DISK_FULL (30) MonSub: No space left in
Destination Path!
MONSUB_FILECOPY_COPROC_ABRUPTLY_KILLED (31) MonSub: File copy co-proc
terminated abruptly!

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
300
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Control Plane SMGR Functionality

Status Code Status Description

MONSUB_LOGGING_COPROC_ABRUPTLY_KILLED (32) MonSub: Logging co-proc
terminated abruptly!
MONSUB_SM_DISCONNECT (33)
MONSUB_FILECOPY_STATUS_MAX (34)
Other Internal Error adding protocol
monitor trace - aborting…

Control Plane SMGR Functionality

Following are the modification in the CP SMGR to support this feature.
• Provide services to the CLI for enabling or disabling the MonSub tracing.
• When you enable the MonSub for a subscriber on Control Plane. The changes propagate to the
corresponding U-Plane over Sx interface as per the instructions from CP CLI.
• Any tracing failures in the UP is reported to the CP (if MonSub enabled via CP console) by a "private
IE Subscriber Trace Status Report" within Sx Session Report Request message from UP to CP.
• The feature supports the tracing of four concurrent subscriber tracing sessions for fast-path and slow-path
PCAP creation from CP per User Plane instance.
• The CP instance sends the CLI instance ID while enabling MonSub from CP, so that the UP sends
notifications to correct CP CLI instance ID.

Note There’s a race condition scenario when you enable the tracing for new/camp-on call. When the UE attach is
in progress, private IE is sent in either Sx Establish Req or the Sx modify (existing attach sequence, so that
the attach flow isn’t disturbed). For existing calls, the private IE is sent in the Sx modify request.

User Plane SMGR Functionality

Following are the modification in the UP SMGR to support this feature.
• Provide services to the CLI for enabling or disabling the MonSub tracing.
• Based on the MonSub private IE over Sx interface from C-PLANE. Enable or Disable the MonSub
tracing and generate the ‘Subscriber Trace Status Report’ to inform C-PLANE whether tracing is on or
not.
• Control NPUMGR to connect/start/stop/add/delete streams/tep bearers and disconnect.
• The SMGR maintains the PSN from the NPUMGR (as part of CONNECT API) and sub session id, which
is SMGR (local to SMGR instance) specific. The SMGR sends all requests with PSN and sub session id
to NPUMGR for a monitor subscriber tracing session.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
301
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Multi PDN Multi Trace

• Based on the instructions from the CLI, configures panopticon (via NPUMGR) for changes such as
packet size and priority.
• Read the ‘hex dump module’ configurations and store them locally. Pass the relevant parameters (such
as filename) to Session Manager Co-Proc.
• Instantiate Session Manager Co-Proc and then instruct it to copy panopticon generated PCAP files to
hard disk. Also handle the termination of Session Manager Co-Proc when MonSub session is over.
• Handle file copy message from Session Manager Co-Proc and inform panopticon about the copied bundle.
• If the file copy fails or there are problems with Session Manager Co-Proc instantiation, raises the SNMP
alarms.
• Handle the buffer full indications from panopticon and copy the PCAP from the ram disk to the configured
destination directory.
• Capture the control/slow-path packets. Pass them to Session Manager Co-Proc to publish it as a separate
PCAP.
• This feature supports a maximum of four monitor subscriber tracing sessions for a U-PLANE instance.
The NPUMGR enforces the tracing limit.
• The MonSub tracing session terminates in the absence of no space on hard disk or no hard disk.
• There are coproc (file copy and logging) per UP-SMGR instance, when monitor subscriber tracing is
initiated for that SMGR instance.
• The MonSub session tear down takes time depending on the final poll timer and disconnect responses
from co-proc/NPUMGR.

Note There is a race condition scenario while tracing is enabled for new/camp-on call. When the UE attach is in
progress, private IE is sent in either Sx Establish Req or the Sx modify (existing attach sequence, so that the
attach flow is not disturbed). For existing calls, the private IE is sent in the Sx modify request.

Multi PDN Multi Trace

For a multi-PDN call, when you start the MonSub with Multi-trace=OFF, then it traces the only one PDN as
a part of that MonSub session. When new PDN is initiated then existing PDN tracing stops and new PDN
tracing starts. For this, first the new PDN tracing is started and then existing PDN tracing is STOPPED and
hence new PSN and SMGR sub-session ID is allocated.
For a multi-PDN call, when you start the MonSub with Multi-trace=ON, then it traces the new PDN as a part
of new FASTPATH tracing session (that is MonSub session). Hence after tracing the four PDN, MonSub CLI
shows max tracing session reached. Tracing of the each PDN takes place as a separate MonSub session.

Note For Pure-S call, when MonSub starts from CP, then tracing of the multi-PDN happens as a separate FASTPATH
tracing session (that is separate MonSub session) irrespective of MT=ON or OFF.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
302
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
MonSub Stats

MonSub Stats
A new mechanism is added to publish the stats regarding the quality of FASTPATH PCAP capture on MonSub
CLI. The new mechanism publishes the stats whenever it receives the buffer full MEH indication at SESSMGR,
throttled at every five seconds. The feature supports a maximum of four buffers for a FASTPATH PCAP
corresponding to MonSub session. The feature does not publish the stats by default and needs to be enabled
via debug CLI on UP.
• debug uplane monsub-stats disabled
• debug uplane monsub-stats enabled

The stats contains the following informations:

Packet accepted: 14250000 Packet rejected: 62297
Congestion Short Term: 0 Congestion Longer Term: 0
Throttled: 0 PCAP File Transfer Rate: 9.91
mbps

The PCAP file transfer rate is the rate at which copy co-proc writes the PCAP from RAM-FS to HD-RAID.

X-Header
This feature supports the X-Header capture in slow-path PCAP. The P-GW-U inserts the X-HEADER for
Uplink packet. The P-GW-U captures the packet at entry and exit interfaces. So, the exit packet sent to SGI
contains the inserted x-header.
The P-GW-U inserts the X-HEADER for Downlink packet. The P-GW-U captures the packet at entry and
exit interfaces. So, the exit packet sent to S5-U or S1-U contains the inserted x-header.

How It Works
The Monitor Subscriber feature is discussed in detail in the following sections:

Configuration Procedure for Monitor Subscriber

The protocol monitor can be used to display information for a specific subscriber session that is currently
being processed. Depending on the number of protocols monitored, and the number of sessions in progress,
a significant amount of data is generated. It is highly recommended that logging be enabled on your terminal
client in order to capture all of the information that is generated.
Follow the instructions in this section to invoke and configure the protocol monitoring tool for a specific
subscriber session.

Step 1 Invoke the monitor subscriber command from the Exec mode by entering the monitor subscriber CLI command.
monitor subscriber { callid | imei | imsi | ipaddr | ipv6addr |
[local]host_name#
msid | msisdn | next-call | pcf | peer-fa | peer-lac | sgsn-address | type |
username }

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
303
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monsub CLI Options

An output listing all the currently available protocols, each with an assigned number, is displayed. Specify the method
the monitor should use by entering the appropriate keyword.

Step 2 Specify the method the monitor should use by entering the appropriate keyword.
Select other options and/or enter the appropriate information for the selected keyword.

Step 3 Select other options and/or enter the appropriate information for the selected keyword.
If no session matching the specified criteria was being processed when the monitor was invoked, a screen of available
monitoring options appears.

Step 4 Configure the amount of information that is displayed by the monitor. To enable or disable options, enter the letter or
2-digit number associated with that option (C, D, E, 11, 12, etc.). To increase or decrease the verbosity, use the plus ( +
) or minus ( - ) keys.
The current state, ON (enabled) or OFF (disabled), is shown to the right of each option.
Option Y for performing multi-call traces is only supported for use with the GGSN.
WARNING!!! You have selected options that can DISRUPT USER SERVICE
Existing CALLS MAY BE DROPPED and/or new CALLS MAY FAIL!!!
(Under heavy call load, some debugging output may not be displayed)
Proceed? - Select (Y)es or (N)o

Step 5 Repeat step 6 as needed to enable or disable multiple protocols.

Step 6 Press the Enter key to refresh the screen and begin monitoring.
The monitor remains active until disabled. To quit the protocol monitor and return to the prompt, press q.

Monsub CLI Options

Monitor Subscriber CLI – New Options
The following options with their default value are added to existing monitor subscriber command.

Control Plane Monitor Subscriber CLI

Following are the options:
• W - UP PCAP Trace (ON ): This parameter is used to create PCAP trace for slowpath and fastpath and
is only applicable for CUPS.
• U - Mon Display (ON): This parameter is used to capture the control events (such as statistics and charging
information from ECS and so on) on C-PLANE monitor console. Therefore, the default value is being
changed to ON. This parameter value has no impact on U-PLANE.
• V - PCAP Hexdump (OFF): This flag must be set to ON to capture the protocol packets in a text file in
hexdump format on U-PLANE.

Note Currently, UP PCAP Trace flag must be set to ON to capture the fastpath and slowpath PCAP files for CUPS.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
304
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monsub CLI Options

User Plane Monitor Subscriber CLI

Following are the options:
• W - UP PCAP Trace (ON ): This parameter is used to create PCAP trace for slowpath and fastpath and
is only applicable for CUPS.
• U - Mon Display (ON): The non-protocol events (such as statistics and charging information from ECS
and so on) are also captured in slowpath PCAP files and are displayed on U-PLANE monitor console.
• V - PCAP Hexdump (ON): This flag must be set to ON to capture the protocol packets in a text file in
hexdump format on U-PLANE.

Note Currently, UP PCAP Trace flag must be set to ON to capture fastpath and slowpath PCAP files on CUPS.

Monitor Subscriber CLI – New Options

The following options with their default value are added to existing monitor subscriber command.
• F - Packet Capture (Full Pkt): Captures all packets from fastpath.
Using this option, operators can choose between full and partial packet captures. By entering F, the
packet capture type can be changed to either full or partial. With partial packet capture, users can enter
packet sizes from 1 to 16384 bytes. For example, if input is given as 20, only the first 20 bytes of fastpath
packets will be captured and the remaining packets will be dropped.

Note When opening the PCAP file, the summary view will display full length of the
packet, but the detailed view will show only the truncated packet.

• / - Priority (0): The value is in the range from "0 – Best Effort" to "7 – Guaranteed"
• 0 - Best Effort
• 1 - Low
• 2 - Med-Low
• 3 - Medium
• 4 - Med-High
• 5 - High
• 6 - Critical
• 7 - Guaranteed

Caution It is strongly recommended to not change the default value. It can adversely affect
the system performance.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
305
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Context, CDRMOD and Hexdump Interaction for Monitor Subscriber

• N - MEH Header (OFF) : The MEH header is stripped from the IP packet if this option is configured

Show Monitor Subscriber Sessions

Following is the new CLI to show the ongoing MonSub session.
You can trigger the CLI show monitor subscriber fastpath session all from both CP and UP. You can trigger
the show monitor subscriber fastpath session up-ip-address from the CP.
• SessId: This is the local session id for MonSub session on UP Sessmgr.
• CallID: Call id on Userplane.
• PSN: This is panopticon sequence no. There is a maximum of four MonSub fastpath tracing sessions on
one UP with PSN ranging from 0-3.
• Start time: Time at which MonSub tracing session starts.
• Interface Type: This is to identify the call type for which MonSub fastpath tracing session was started,
whether it is Sxa, Sxb or Sxab.

Disconnect Monitor Subscriber Sessions

Following is the new CLI to disconnect the ongoing MonSub session. You can trigger the CLI from both CP
and UP.
monitor subscriber fastpath disconnect sessmgr-instance <UP SMGR Instance ID> session-id <Local
Monitor subscriber Session ID at SMGR instance level>
If the MonSub session disconnect is successful, the following message dispalys on console.
Session Disconnected Successfully

If the MonSub session disconnect fails, the following message dispalys on console.
Monitor Subscriber session does not exist

Note Only security administrator can execute the monitor disconnect CLI.

Context, CDRMOD and Hexdump Interaction for Monitor Subscriber

Hexdump module must be configured to provide operators the provision to configure Files names and Poll
timers. The Hexdump module is one of the modules such as—EDR, UDR and so on, that are part of the
CDRMOD functionality. It is recommended to configure the hexdump in a non-local context such as the ECS
context. Hexdump modules are not supported in local context.
For more information on Hexdump module and its configuration, refer to the Packet Capture (PCAP) Trace
chapter in the ASR5500 System Administration Guide

PCAP File Name Convention

The naming conventions for PCAP files are discussed in the following sections

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
306
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
PCAP File Name Convention

Note Only monitor-subscriber-file-name and rotation options are used in naming PCAP files.

Slowpath File Name Convention

The slow path file names appear in the following format:
curr_slowpath_{SMGR Mon Sub Session
Id}_{monsub_file_name_option_val}_{Timestamp}_{RotationCount}.pcap

or
slowpath_{SMGR Mon Sub Session
Id}_{monsub_file_name_option_val}_{Timestamp}_{RotationCount}.pcap

File with ‘curr_’ prefix is the file, that is currently being written to, that is still not closed. When files are to
be rotated (depending on the file rotation parameters), file without the ‘curr_’ prefix are copied to hard disk.
The SMGR MonSub Session Id – This is the session Id for MonSub session created on Uplane SMGR instance
ID, which created this PCAP. This Id is local to SMGR instance, so there could be two SLOWPATH pcap
captured with same ID.
When files are to be copied to hard disk, The monsub_file_name_option_val is replaced by:
• IMSI value if monitor-subscriber-file-name is set to "imsi".
• Call ID value if monitor-subscriber-file-name is set to "call-id"
• Username value if monitor-subscriber-file-name is set to ‘username’

Timestamp is in the following format "MMDDYYYYHHMMSS", where:

• MM - Month, DD - Date and YYYY - Year.
• HH -Hour, MM - Minutes and SS - Seconds.

RotationCount is a 9-digit value that is incremented every time an old file is rotated, and a new file is generated.
00000000 for the first file, 00000001 for the second file and so on.
Rotation of slowpath files is determined by following option in hexdump-module file configuration:
rotation { num-records number | time seconds| volume bytes }
• num-records: num-records specifies the number of packets after which a new file is generated and
‘RotationCount’ in the filename is incremented. The range of number is between 100 to 10240, and the
default value is 1024.
• time: time specifies the time to wait in seconds before a new file is generated and ‘RotationCount’ in
the filename is incremented. seconds must be an integer from 30 through 86400. The default value is
3600.
• volume: volume specifies the number of bytes after which a new file is generated and ‘RotationCount’
in the filename is incremented. bytes must be an integer from 51200 through 62914560. The default
value is 102400.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
307
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
PCAP File Name Convention

Note The tarriff-time parameter under rotation is ignored as it is not suitable for PCAP file capture.

The following are examples of the file naming conventions for slowpath PCAP files.
• For the ‘imsi’ option where IMSI is ‘112233445566778’, slowpath files are named as:
slowpath_S0_112233445566778_07152019050907_000000000.pcap

• For ‘call_id’ option where Call Id is ‘01317b22’, slowpath files are named as:
slowpath_S0_01317b22_07152019050907_000000000.pcap

Note The parameter tarrif-time is not applicable for PCAP file capture.

Fastpath File Name Convention

The fastpath file names appear in the following format:
vpp_{S}_{B}_{encap}_{monsub_file_name_option}_{Timestamp}_{FileCount}.pcap

• S is replaced by either ‘S1’, ‘S2’,'S3’, or 'S4’.

• B is replaced by either ‘B0’,‘B1’,'B2', or 'B3' depending on the bundle generated by Panopticon.
• monsub_file_name_option is replaced by:
• IMSI value if monitor-subscriber-file-name is set to "imsi".
• Call ID value if monitor-subscriber-file-name is set to "call-id"
• Username value if monitor-subscriber-file-name is set to ‘username’

Timestamp is in the following format "MMDDYYYYHHMMSS", where:

• MM - Month, DD - Date and YYYY - Year.
• HH -Hour, MM - Minutes and SS - Seconds.

RotationCount is a 9-digit value that is incremented every time an old file is rotated, and a new file is generated.
00000000 for the first file, 00000001 for the second file and so on.
Fast path "FileCount" is not the same as the slowpath "RotationCount" parameters and hence ‘hexdump-module
file rotation’ parameters are ignored while naming fastpath files.
In Phases 1 of the feature, fastpath generated file names are like ‘vpp_S1_B0_ip.pcap’ or ‘vpp_S1_B1_ip.pcap’,
they are renamed to following when being copied over to non-volatile storage:
• vpp_S1_B0_ip_01317b22_07152019050907_000000000.pcap
• vpp_S1_B1_ip_01317b22_07152019050908_000000001.pcap
• vpp_S1_B0_ip_01317b22_07152019050908_000000002.pcap

In MonSub phase 3, a PCAP “bundle” is replaced with a single PCAP file that uses Ethernet encapsulation.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
308
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
PCAP File Location

In Phase 3, each fastpath session file is captured in the Ethernet PCAP file that is ‘vpp_S0_B0_eth.pcap’ and
they are renamed to following when being copied to a non-volatile storage:
vpp_S0_B0_eth_01317b22_07152019050907_000000000.pcap

For ‘callid’ option where Call Id is ‘12345678ef’:

• slowpath_S0_12345678ef _07152019050907_000000000.pcap

• vpp_S1_B0_eth_12345678ef _07152019050907_000000000.pcap

For ‘username’ option where username is ‘9890098900’:

• slowpath_S0_07152019050907_000000000_9890098900.pcap
• vpp_S1_B0_eth_07152019050907_000000000_9890098900.pcap

PCAP File Location

Fastpath PCAP files are written to the /records/pcap directory in same card and CPU complex where the
SMGR owns the subscriber session resides.
/records directory is mapped to the "tmpfs" filesystem that is mapped to RAM. In this state, the files are
suffixed with a ".pending" extension. For example:
-rw-rw-r-- 1 root root 268599296 Sep 23 14:04 vpp_S1_B0_eth.pending

Note The files size at this stage is not the actual file size when it is written to a persistent storage.

Once the fastpath tracing mechanism has written the files, they are converted to ‘.pcap’ files and renamed as
given below. Additionally, there is a file that ends with a ".done" extension:
-rw-rw-r-- 1 root root 8689188 Oct 16 22:06 vpp_S0_B0_eth.pcap

After the PCAP files are written by fastpath tracing mechanism, the Co-Proc functionality instantiates and
copies the files to a hard disk or a persistent storage.
The above file location process for Fastpath is also applicable to Slowpath.
The target file location in all cases is: /hd_raid/records/hexdump, except for the case in the hexdump module
configuration where use-harddisk is enabled and the directory option under the hexdump file is to a custom
value. For example, if the directory option is set to a value "abc" then the target location for the PCAP file
will be: /hd_raid/records/hexdump/abc/.
In this feature implementation, a predefined location is set for PCAP files
• To make sure that /records/pcap directory is not populated when issues are encountered with the use
of use-harddisk and hexdump module configurations.
• For regular cleanup from /hd_raid/records/hexdump directory.

File Transfer to External Location

Once the files have been copied to the hard disk, they can be copied over to external server using the command:
transfer-mode option under the hexdump command in the hexdump-module configuration.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
309
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Limitations

Apart from transfer-mode, other relevant options under hexdump can be used for external file transfer.
Operators can use these commands to avoid excessive storage during fastpath processing.

Limitations
Following are the Limitations:
•
• Restarting trace immediately after quitting may result in fastpath files in /records/pcap directory to be
overwritten. It is recommended to restart the session after a brief moment (a few seconds).
•
•
• When MonSub trace is stopped, the tear down process can take a few seconds, so it is recommended to
wait for few seconds. A maximum of (5sec, hexdump poll timer value in sec) before toggling the MonSub
trace to start, else operators may observe MAX TRACING SESSIONS REACHED momentarily.
• Show monitor subscriber fastpath sessions CLI does not display the MonSub sessions that are being
stopped. Hence there is a transient period where new MonSub sessions can be rejected due to max sessions
reached, whereas show CLI shows less sessions. It is recommended that operators wait for some time
before starting a new MonSub trace session.
• For Pure-S call, when MonSub started from CP, then multi-PDN is traced as a separate FASTPATH
tracing session (that is separate mon sub session) irrespective of MT=ON or OFF.
• Changing fastpath configuration options is only possible when UP Pcap Trace is set to OFF.
• When MT=ON in the Multi-PDN, then once MT=OFF, new PDN tracing is not started due to MAX
TRACING REACHED, and then all other tracing is STOPPED. This is because the first new PDN tracing
is started and then all previous PDN's were STOPPED for MT=OFF case.
• It is recommended to not to launch the same UE MonSub sessions from different CLIs.
• In slowpath PCAP, the egress DL packets does not show the GTPU-U header because the functionality
to add GTP-U is with fastpath. So, ingress and egress DL packets shows up the duplicates, unless there
is some packet modification like HTTP X-headers applied over the ingress packets.
• Toggling C and D options does not impact the PCAP captures in CUPS.
• For Multi-PDN, the fastpath filenames does not use the Call Id, because, by definition the multi-PDN
case has more than one call id and hence a higher-level configuration such as IMSI is more suitable for
naming the files.
• Only the named options explicitly mentioned in this document are supported from hexdump-module file
configuration.
• Number of streams that can be traced in fastpath is limited to 5000. Stream is defined as a TCP or UDP
flow which is made up of {source IP address, destination IP address, source port, and destination port,
transport protocol such as TCP or UDP).
• Fastpath packets cannot be streamed to an external server. They are stored on the hard-disk and transferred
(either manually) or by using transfer-mode options.
• The UP PCAP trace must be set to ON to capture fastpath and slowpath PCAP files.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
310
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Configuring the Hexdump Module for MonSub in CUPS

• MonSub CLI option ‘<SPACE> Pause’ is only to pause console events. There is no impact on other
tracing events (slowpath PCAP, fastpath PCAP and protocol packets tracing in a text file in hexdump
format) with this option.
• The UP trace PCAP file does not contain the initial PFCP Sx Request/Response, due to race condition.
• The ICMP Packets and a first packets of TCP and UDP streams flow through both slowpath and fastpath.
Default values of GTPU (option 26) and User L3 (Option 19) are set to OFF. As a result, these packets
are not captured in slowpath captures. If Option 26 is set to ON then these packets are captured in slowpath
PCAP captures. As mentioned in previous point, option 19 has no effect on slowpath PCAP capture.
• Data Events flag must be set to ON to capture fastpath and slowpath PCAP files.
• Only first PDN tracing is supported for Pure-S call. This limitation will be fixed with multiple subscriber
tracing support.
• The Mon sub tracing is not supported for option Next-SAEGW Call on UP.
• The Mon sub tracing is not supported for option Next call by APN for Pure-S call type.
• On ASR-5500 setup with the default value of poll-timer, all the packets may not be captured due to a
known issue. To avoid large number of packets to be rejected, it is recommended to change the poll-timer
value to the lowest possible (10ms).
• If context replacement occurs (if the same subscriber reattaches without a detach) then the slowpath
captures for the new call continues to be in the old slowpath files.

Configuring the Hexdump Module for MonSub in CUPS

Configuring MonSub Poll Timer
Use this configuration to set the frequency of PCAP file capture check.
configure
context context_name
hexdump-module
hexdump monitor-subscriber-poll-timeout poll_timer_value
end
NOTES:
• hexdump monitor-subscriber-poll-timeout : This option specifies how frequently the check for newly
captured PCAP files in the volatile storage must be done before they are copied to persistent storage.
• poll_timer_value: Specifies the poll timer value in milliseconds. It must be an integer in the range of 10
ms to 60 seconds. Default: 30 seconds.

Note It is strongly recommended to not configure the timer with a value less than 5
seconds.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
311
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Configuring MonSub File Name

• This option is only applicable when MonSub is enabled for the products that have fastpath
functionality—PGW, SAEGW on ASR-5500 and VPC-SI.

Configuring MonSub File Name

Use the following configuration to specify the file name of the PCAP file which contains IMSI, Call ID or
Username.
configure
context context_name
hexdump-module
file rotation { num-records number | tariff-time minute minutes hour
hours | time seconds| volume bytes | monitor-subscriber-file-name { imsi |
username | call-id }
end
NOTES:
• monitor-subscriber-file-name { imsi | username | call-id }: This option specifies if the name of the
captured PCAP files will contain IMSI, Call Id or Username. This option is only applicable on products
that have fastpath functionality (PGW, SAEGW on ASR-5500 and VPC-SI) AND only when Monitor
Subscriber functionality is enabled. Default: IMSI.
• rotation { num-records number | tariff-time minute minutes hour hours | time seconds | volume bytes
}: Specifies when to close a hexdump file and create a new one.
• num-records number : Specifies the maximum number of records that should be added to a hexdump
file. When the number of records in the file reaches this value, the file is complete.
number must be an integer from 100 through 10240. Default: 1024
• tariff-time minute minutes hour hours : Specifies to close the current hexdump file and create a
new one based on the tariff time (in minutes and hours).
minutes must be an integer from 0 through 59.
hours must be an integer from 0 through 23.
• time seconds : Specifies the period of time to wait (in seconds) before closing the current hexdump
file and creating a new one.
seconds must be an integer from 30 through 86400. Default: 3600

Important It is recommended to set the rotation time to 30 seconds.

• volume bytes : Specifies the maximum size of the hexdump file (in bytes) before closing it and
creating a new one.
bytes must be an integer from 51200 through 62914560. Note that a higher setting may improve the
compression ratio when the compression keyword is set to gzip. Default: 102400

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
312
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
Monitoring and Troubleshooting

Monitoring and Troubleshooting

This section provides information regarding monitoring and troubleshooting the Monitor Subscriber feature.

SNMP Traps
The following SNMP trap(s) are added in support of the Monitor Subscriber feature:
• MonSubProcessInitFailure: This trap is triggered when MonSub handler process has failed for a particular
process and service.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
313
 Cisco Confidential - Limited Release
Monitor Subscriber for CUPS
SNMP Traps

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
314
 Cisco Confidential - Limited Release

CHAPTER 42
MPLS Support on VPC-SI for CUPS
• Revision History, on page 315
• Feature Description, on page 315
• How it Works, on page 316
• Monitoring and Troubleshooting, on page 316

Revision History
Revision Details Release

First introduced. 21.15.1

Feature Description
In the existing platforms (VPC-DI, ASR 5500), the boxer supports MPLS, which uses the underlying dataplane
forwarder to switch MPLS traffic. In ASR 5500, the NP4c network processor generates and processes MPLS
traffic while in VPC-DI, the IFTask generates and processes MPLS traffic.
The MPLS Support on VPC-SI for CUPS feature enables MPLS support on VPC-SI (SI-CUPS), which uses
VPP as the dataplane forwarder.
VPP supports and provides multiple dataplane features that include the MPLS stack as a separate graph node.
VPP generates labeled packets and simultaneously processes incoming labeled packets. This helps differentiate
between different customer VRFs to support a large number of corporate APNs having different addressing
models and requirements.
The MPLS Support on VPC-SI for CUPS feature supports the following functionalities:
• Uses the VPP MPLS stack to send the MPLS labeled packet.
• Uses the VPP MPLS stack to process the incoming labeled MPLS packet.
• Supports all existing MPLS configuration (VPC-DI, ASR 5500) and provides feature parity with new
deployments using VPC-SI CUPS.
• Supports VPPCTL CLI commands to display NHLFE and ILM tables that are in VPP for debugging and
comparing values with boxer configuration.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
315
 Cisco Confidential - Limited Release
MPLS Support on VPC-SI for CUPS
How it Works

How it Works
This section briefly describes how the MPLS Support on VPC-SI for CUPS works.
In the current CUPs architecture, VPP forwarder provides its own MPLS stack, which supports all the existing
functionalities for MPLS packet processing. The VPP MPLS stack is configured with the appropriate Next-Hop
Label Forwarding Entry (NHLFE) and incoming label map (ILM) tables. This helps generate the MPLS packet
on the egress with the correct MPLS header. It also processes the incoming MPLS packet and switches this
packet based on the incoming labels to the appropriate next hop table identifier (VRF context of the subscriber)
based on the incoming label.

Monitoring and Troubleshooting

This section provides information regarding the CLI command available in support of monitoring and
troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show mpls fn vpp

The output of this CLI command contains the following new field for the MPLS Support on VPC-SI for CUPS
feature:
• vpp
• all-vrf
• summary
• vrf

Note This new field enables viewing of the VPP dataplane values that are confiigured in the VPP dataplane forwarder.
This show command is used for debugging along with the existing debug commands.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
316
 Cisco Confidential - Limited Release

CHAPTER 43
Multiple Control Plane Support on User Plane
• Revision History, on page 317
• Feature Description, on page 317
• How it Works, on page 318
• Configuring Multiple Control Plane Support on User Plane, on page 320
• Monitoring and Troubleshooting, on page 320
• Sample RCM Configuration, on page 324

Revision History
Revision Details Release

First introduced. 21.19.1

Feature Description
In releases prior to 21.19.1, the CUPS architecture supported only a single Sx interface between User Plane
(UP) and Control Plane (CP). In 21.19.1 and later releases, this feature enables single UP to establish multiple
Sx interfaces to multiple CPs. Multiple Sx peers in a CP group are configured on UP to establish multiple Sx
associations between a single UP and multiple CPs.

Note • Both CP and UP are separately configured.

• Instead of a PFD push, the Redundancy and Configuration Management (RCM) pushes the configuration
on UP.
• It's recommended not to configure more than four CP peer IP addresses in a single CP group.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
317
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
How it Works

How it Works
To configure multiple CPs with different Active Charging System (ACS) service, this feature leverages
Redundancy and Configuration Management (RCM) functionality to push a super-set of configuration to UP.

Prerequisites
The following prerequisites must be met to configure multiple CPs:
• Ruledef:
UP provides UE service with different rule definition (Ruledef) configurations on multiple CPs under
the same ACS (ECS) service. However, the Ruledef with the same name on different CPs must be
common. For example, the following table shows Ruledef configurations on multiple CPs.

CP1 CP2 CP3 CP4

Rule_def 1 Rule_def 2 Rule_def 3 Rule_def 4
Rule_def 4 Rule_def 1 Rule_def 2 Rule_def 3

• Group-of-Ruledefs (GoR):
UP provides UE service with different Group-of-Ruledefs (GoR) configurations on multiple CPs under
the same ACS (ECS) service. However, the GoR with the same name on different CPs must be common.
For example, the following table shows GoR configurations on multiple CPs.

CP1 CP2 CP3 CP4

GoR 1 GoR 2 GoR 3 GoR 4
GoR 4 GoR 1 GoR 2 GoR 3

• Rulebase:
UP provides UE service with different Rulebase configurations on multiple CPs under the same ACS
(ECS) service. However, the rulebase with the same name on different CPs must be common. For example,
the following table shows Rulebase configurations on multiple CPs.

CP1 CP2 CP3 CP4

RB 1 RB 2 RB 3 RB 4
RB 4 RB 1 RB 2 RB 3

• IP Pools:
Each CP must be configured with mutually exclusive IP pools. For example, the following table shows
IP Pool configurations on multiple CPs.

CP1 CP2 CP3 CP4

Pool 1 Pool 3 Pool 5 Pool 7
Pool 2 Pool 4 Pool 6 Pool 8

• APN:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
318
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
How it Works

Each CP must be configured with mutually exclusive APN. For example, the following table shows APN
configurations on multiple CPs.

CP1 CP2 CP3 CP4

APN 1 APN 3 APN 5 APN 7
APN 2 APN 4 APN 6 APN 8

• Egress Context
Each CP must be configured with a different egress context. To push the IP pools from a CP to a specific
egress context on a UP, the UP must be configured with all the egress contexts present on different CPs.
For example, the following table shows egress context configurations on multiple CPs.

CP1 CP2 CP3 CP4

ISP1-CP1 ISP1-CP2 ISP1-CP4 ISP1-CP4

For example, the following table shows egress context configurations on multiple UPs.

UP1 UP2
ISP1-CP1 ISP1-CP1
ISP1-CP2 ISP1-CP2
ISP1-CP3 ISP1-CP3
ISP1-CP4 ISP1-CP4

The following image shows a sample RCM configuration of two CPs communicating with two UPs.
Figure 13: Sample RCM Configuration of Two CPs Communicating with Two UPs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
319
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Configuring Multiple Control Plane Support on User Plane

Configuring Multiple Control Plane Support on User Plane

This section provides information about CLI commands that are available in support of this feature.

Disabling PFD Configuration Push from CP

As configuration push to UP is done through RCM, use the following CLI commands to disable PFD
configuration push from CP.
configure
user-plane-group group_name
sx-pfd-push disabled
end

Configuring Multiple CP on UP
Use the following CLI commands to configure multiple CP on UP by adding multiple peer node under Control
Plane Group Configuration mode.
configure
control-plane-group group_name
peer-node-id ipv4-address ipv4_address
peer-node-id ipv4-address ipv4_address
end

Monitoring and Troubleshooting

This section provides information about monitoring and troubleshooting the Multiple CP Support on UP
feature.

Show Commands and/or Outputs

This section describes the show commands that are available in support of this feature.

show sx-service statistics address <ip_address>

Use this command to display Sx statistics for a CP node. The following is a sample output:
Session Management Messages:
Session Establishment Request:
Total TX: 0 Total RX: 2
Initial TX: 0 Initial RX: 2
Retrans TX: 0 Retrans RX: 0
Discarded: 0
No Rsp RX: 0
Throttled: 0

Session Establishment Response:

Total TX: 2 Total RX: 0
Initial TX: 2 Initial RX: 0
Accepted: 2 Accepted: 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
320
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
show sx-service statistics address <ip_address>

Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Session Modification Request:

Total TX: 0 Total RX: 10
Initial TX: 0 Initial RX: 10
Retrans TX: 0 Retrans RX: 0
Discarded: 0 Intf Type Mismatch: 0
No Rsp RX: 0

Session Modification Response:

Total TX: 10 Total RX: 0
Initial TX: 10 Initial RX: 0
Accepted: 10 Accepted: 0
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Session Deletion Request:

Total TX: 0 Total RX: 2
Initial TX: 0 Initial RX: 2
Retrans TX: 0 Retrans RX: 0
Discarded: 0
No Rsp RX: 0

Session Deletion Response:

Total TX: 2 Total RX: 0
Accepted: 2 Accepted: 0
Denied: 0 Denied: 0
Discarded: 0

Session Report Request:

Total TX: 3 Total RX: 0
Initial TX: 3 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
Discarded: 0
No Rsp RX: 0

Session Report Response:

Total TX: 0 Total RX: 3
Initial TX: 0 Initial RX: 3
Accepted: 0 Accepted: 3
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Node Management Messages:

Prime PFD Management Request:
Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
No Rsp received TX: 0 Discarded: 0

Prime PFD Management Response:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Accepted: 0 Accepted: 0
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Association Setup Request:

Total TX: 1 Total RX: 0
Initial TX: 1 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
No Rsp received TX: 0 Discarded: 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
321
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
show sx-service statistics address <ip_address>

Association Setup Response:

Total TX: 0 Total RX: 1
Initial TX: 0 Initial RX: 1
Accepted: 0 Accepted: 1
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Association Update Request:

Total TX: 0 Total RX: 3
Initial TX: 0 Initial RX: 3
Retrans TX: 0 Retrans RX: 0
No Rsp received TX: 0 Discarded: 0

Association Update Response:

Total TX: 3 Total RX: 0
Initial TX: 3 Initial RX: 0
Accepted: 3 Accepted: 0
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Association Release Request:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
No Rsp received TX: 0 Discarded: 0

Association Release Response:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Accepted: 0 Accepted: 0
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Node Report Request:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
No Rsp received TX: 0 Discarded: 0

Node Report Response:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Accepted: 0 Accepted: 0
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Heartbeat Request:
Total TX: 1398 Total RX: 1398
Initial TX: 1398 Initial RX: 1398
Retrans TX: 0

Heartbeat Response:
Total TX: 1398 Total RX: 1398

Stats framework related messages:

Stats Query Request:
Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
No Rsp received TX: 0 Discarded: 0

Stats Query Response:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
322
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
show user-plane-service statistics peer-address <ip_address>

Accepted: 0 Accepted: 0
Denied: 0 Denied: 0
Retrans TX: 0 Discarded: 0

Stats Query Acknowledgement:

Total TX: 0 Total RX: 0
Initial TX: 0 Initial RX: 0
Retrans TX: 0 Retrans RX: 0
Discarded: 0

Total Signalling Packets:

TX: 21 RX: 21

Total Signalling Bytes:

TX: 2092 RX: 5381

Use the clear sx-service statistics address ip_address CLI command to clear Sx statistics for a CP node.

show user-plane-service statistics peer-address <ip_address>

Use this command to display the node-level service statistics for a UP. The following is a sample output:
Peer IP : 192.0.2.1

Subscribers Total:
PDNs Total:
Active: 1 Setup: 1
Released: 0 Rejected: 0

PDNs By PDN-Type:
IPv4 PDNs:
Active: 1 Setup: 1
Released: 0

IPv6 PDNs:
Active: 0 Setup: 0
Released: 0

IPv4v6 PDNs:
Active: 0 Setup: 0
Released: 0

eMPS PDNs Total:

Active: 0 Setup: 0
Released: 0 Rejected: 1

PDNs By interface-Type:
Sxa interface-type PDNs:
Active: 0 Setup: 0
Released: 0

Sxb interface-type PDNs:

Active: 1 Setup: 1
Released: 0

Sxab interface-type PDNs:

Active: 0 Setup: 0
Released: 0

N4 interface-type PDNs:
Active: 0 Setup: 0
Released: 0

PDNs Rejected By Reason:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
323
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

No Resource: 0 Missing or unknown APN: 0

Addr not alloc: 0 Addr not present: 0
No memory available: 0 System Failure: 0
Rule install failed: 0 SFW policy mismatch: 0

PDNs Released By Reason:

Network initiated release: 0 Admin disconnect: 0

Total Data Statistics:

Uplink : Downlink :
Total Pkts: 0 Total Pkts: 0
Total Bytes: 0 Total Bytes: 0
Total Dropped Pkts: 0 Total Dropped Pkts: 0
Total Dropped Bytes: 0 Total Dropped Bytes: 0

Data Statistics Per PDN-Type:

IPv4 PDNs:
Uplink : Downlink :
Total Pkts: 0 Total Pkts: 0
Total Bytes: 0 Total Bytes: 0

IPv6 PDN Data Statistics:

Uplink : Downlink :
Total Pkts: 0 Total Pkts: 0
Total Bytes: 0 Total Bytes: 0

IPv4v6 PDN Data Statistics:

Uplink : Downlink :
Total Pkts v4: 0 Total Pkts v4: 0
Total Bytes v4: 0 Total Bytes v4: 0
Total Pkts v6: 0 Total Pkts v6: 0
Total Bytes v6: 0 Total Bytes v6: 0

Use the clear user-plane-service statistics peer-address ip_address CLI command to clear the node-level
service statistics for a UP.

Sample RCM Configuration

The following is a sample RCM configuration to configure the feature.
configure
etcd replicas 1
endpoint rcm-chkptmgr
replicas 7
vip-ip 1.1.1.1
exit
endpoint rcm-configmgr
vip-ip 1.1.1.1
exit
endpoint rcm-bfdmgr
vip-ip 1.1.1.2
exit
endpoint rcm-controller
vip-ip 1.1.1.1
exit
logging level application trace
logging level transaction trace
logging level tracing off
logging name infra.config.core level application trace
logging name infra.config.core level transaction trace
logging name infra.resource_monitor.core level application debug
logging name infra.resource_monitor.core level transaction debug

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
324
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

k8 smf profile rcm-config-ep disable-cm apn gtpp creditCtrl packetFilter urrList ruledef
rulebase miscacs global chargingAction upfCpg upSvcs sxService gtpuService upfIfc
lawfulIntercept apnprofile
k8 smf profile rcm-bfd-ep bfd-monitor group 1
endpoint ipv4 1.1.1.3
endpoint ipv4 1.1.1.4
endpoint ipv4 1.1.1.5
standby 1
exit
system mode running
helm default-repository smf
helm repository smf
access-token
dev-deployer.gen:AKCp5ekcXA7TknM9DbLASNBw4jwVEsx9Z9WpQwEvCvCQ2mJhLymcz6BfbH38YJiWC6fn1cKmw
url http://example.com
exit
k8s name unknown
k8s namespace rcm
k8s nf-name rcm
k8s registry dockerhub.xxx.com/smi-fuse-docker-internal
k8s single-node false
k8s use-volume-claims false
k8s ingress-host-name 1.1.1.1.nip.io
profile smf rcm
node-id 123456
exit
svc-type upinterface
svc-type sxsvc
svc-type upsvc
svc-type gtpusvc
svc-type cpgrp
redundancy-group 1
host 1.1.1.1:22
host 295 "config "
host 296 "control-plane-group CPGROUP21 "
host 297 "peer-node-id ipv4-address 1.1.1.6 "
host 298 "peer-node-id ipv4-address 1.1.1.7 "
host 299 "exit "
host 300 "end "
exit
exit
svc-type sxsvc
svc-type upsvc
svc-type gtpusvc
svc-type cpgrp
redundancy-group 1
host 1.1.1.1:22
host 393 " config "
host 394 "control-plane-group CPGROUP21 "
host 395 "peer-node-id ipv4-address 1.1.1.6 "
host 396 "peer-node-id ipv4-address 1.1.1.7 "
host 397 "48 exit "
host 398 "49 end "
exit
exit
exit
redundancy-group 1
common 1 " sleep 5 "
common 2 " config "
common 3 " active-charging service ACS "
common 4 " #exit "
common 5 " ruledef ipv6 "
common 6 " icmpv6 any-match = TRUE "
common 7 " #exit "

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
325
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

common 8 " ruledef qci1 "

common 9 " tcp src-port = 1001 "
common 10 " #exit "
common 11 " ruledef qci2 "
common 12 " tcp src-port = 1002 "
common 13 " #exit "
common 14 " ruledef qci6 "
common 15 " tcp src-port = 1006 "
common 16 " #exit "
common 17 " ruledef qci6-CP1 "
common 18 " udp src-port = 1010 "
common 19 " #exit "
common 20 " ruledef qci6-CP2 "
common 21 " udp src-port = 1020 "
common 22 " #exit "
common 23 " group-of-ruledefs GOR "
common 24 " add-ruledef priority 11 ruledef qci1 "
common 25 " add-ruledef priority 22 ruledef qci2 "
common 26 " add-ruledef priority 33 ruledef ipv6 "
common 27 " #exit "
common 28 " group-of-ruledefs GOR-CP1 "
common 29 " add-ruledef priority 11 ruledef qci1 "
common 30 " add-ruledef priority 33 ruledef ipv6 "
common 31 " #exit "
common 32 " group-of-ruledefs GOR-CP2 "
common 33 " add-ruledef priority 11 ruledef qci2 "
common 34 " add-ruledef priority 33 ruledef ipv6 "
common 35 " #exit "
common 36 " packet-filter ipv6 "
common 37 " ip protocol = 58 "
common 38 " priority 22 "
common 39 " #exit "
common 40 " packet-filter qci1 "
common 41 " ip protocol = 6 "
common 42 " ip remote-port = 1001 "
common 43 " priority 1 "
common 44 " #exit "
common 45 " packet-filter qci2 "
common 46 " ip protocol = 6 "
common 47 " ip remote-port = 1002 "
common 48 " priority 2 "
common 49 " #exit "
common 50 " packet-filter qci6 "
common 51 " ip protocol = 6 "
common 52 " ip remote-port = 1006 "
common 53 " priority 6 "
common 54 " #exit "
common 55 " packet-filter qci6-CP1 "
common 56 " ip protocol = 17 "
common 57 " ip remote-port = 1010 "
common 58 " priority 1 "
common 59 " #exit "
common 60 " packet-filter qci6-CP2 "
common 61 " ip protocol = 17 "
common 62 " ip remote-port = 1020 "
common 63 " priority 1 "
common 64 " #exit "
common 65 " urr-list URR_ID_LIST "
common 66 " rating-group 1 urr-id 1 "
common 67 " rating-group 2 urr-id 2 "
common 68 " rating-group 3 urr-id 3 "
common 69 " rating-group 4 urr-id 4 "
common 70 " rating-group 5 urr-id 5 "
common 71 " rating-group 6 urr-id 6 "

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
326
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

common 72 " rating-group 7 urr-id 7 "

common 73 " rating-group 8 urr-id 8 "
common 74 " rating-group 9 urr-id 9 "
common 75 " rating-group 10 urr-id 10 "
common 76 " rating-group 11 urr-id 11 "
common 77 " rating-group 12 urr-id 12 "
common 78 " rating-group 13 urr-id 13 "
common 79 " rating-group 14 urr-id 14 "
common 80 " #exit "
common 81 " charging-action ipv6 "
common 82 " content-id 11 "
common 83 " billing-action egcdr "
common 84 " billing-action rf "
common 85 " cca charging credit rating-group 11 "
common 86 " qos-class-identifier 5 "
common 87 " flow limit-for-bandwidth id 2 "
common 88 " tft packet-filter ipv6 "
common 89 " #exit "
common 90 " charging-action qci1 "
common 91 " content-id 1 "
common 92 " billing-action egcdr "
common 93 " billing-action rf "
common 94 " cca charging credit rating-group 1 "
common 95 " qos-class-identifier 1 "
common 96 " flow limit-for-bandwidth id 1 "
common 97 " allocation-retention-priority 1 pvi 0 pci 1 "
common 98 " tft packet-filter qci1 "
common 99 " #exit "
common 100 " charging-action qci1-GOR "
common 101 " content-id 1 "
common 102 " billing-action egcdr "
common 103 " billing-action rf "
common 104 " cca charging credit rating-group 1 "
common 105 " qos-class-identifier 1 "
common 106 " flow limit-for-bandwidth id 1 "
common 107 " allocation-retention-priority 1 pvi 0 pci 1 "
common 108 " tft packet-filter ipv6 "
common 109 " tft packet-filter qci1 "
common 110 " tft packet-filter qci2 "
common 111 " #exit "
common 112 " charging-action qci1-GOR-CP1 "
common 113 " content-id 1 "
common 114 " billing-action egcdr "
common 115 " billing-action rf "
common 116 " cca charging credit rating-group 1 "
common 117 " qos-class-identifier 1 "
common 118 " flow limit-for-bandwidth id 1 "
common 119 " allocation-retention-priority 1 pvi 0 pci 1 "
common 120 " tft packet-filter ipv6 "
common 121 " tft packet-filter qci1 "
common 122 " #exit "
common 123 " charging-action qci1-GOR-CP2 "
common 124 " content-id 1 "
common 125 " billing-action egcdr "
common 126 " billing-action rf "
common 127 " cca charging credit rating-group 1 "
common 128 " qos-class-identifier 1 "
common 129 " flow limit-for-bandwidth id 1 "
common 130 " allocation-retention-priority 1 pvi 0 pci 1 "
common 131 " tft packet-filter ipv6 "
common 132 " tft packet-filter qci2 "
common 133 " #exit "
common 134 " charging-action qci2 "
common 135 " content-id 2 "

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
327
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

common 136 " billing-action egcdr "

common 137 " billing-action rf "
common 138 " cca charging credit rating-group 2 "
common 139 " qos-class-identifier 2 "
common 140 " flow limit-for-bandwidth id 1 "
common 141 " allocation-retention-priority 2 pvi 0 pci 1 "
common 142 " tft packet-filter qci2 "
common 143 " #exit "
common 144 " charging-action qci6 "
common 145 " content-id 6 "
common 146 " billing-action egcdr "
common 147 " billing-action rf "
common 148 " cca charging credit rating-group 6 "
common 149 " qos-class-identifier 6 "
common 150 " flow limit-for-bandwidth id 2 "
common 151 " allocation-retention-priority 6 pvi 0 pci 1 "
common 152 " tft packet-filter qci6 "
common 153 " #exit "
common 154 " charging-action qci6-CP1 "
common 155 " content-id 12 "
common 156 " billing-action egcdr "
common 157 " billing-action rf "
common 158 " cca charging credit rating-group 12 "
common 159 " qos-class-identifier 6 "
common 160 " flow limit-for-bandwidth id 2 "
common 161 " allocation-retention-priority 6 pvi 0 pci 1 "
common 162 " tft packet-filter qci6-CP1 "
common 163 " #exit "
common 164 " charging-action qci6-CP2 "
common 165 " content-id 13 "
common 166 " billing-action egcdr "
common 167 " billing-action rf "
common 168 " cca charging credit rating-group 13 "
common 169 " qos-class-identifier 6 "
common 170 " flow limit-for-bandwidth id 2 "
common 171 " allocation-retention-priority 6 pvi 0 pci 1 "
common 172 " tft packet-filter qci6-CP2 "
common 173 " #exit "
common 174 " bandwidth-policy bw_policy1 "
common 175 " flow limit-for-bandwidth id 1 group-id 1 "
common 176 " flow limit-for-bandwidth id 2 group-id 2 "
common 177 " group-id 1 direction downlink peak-data-rate 256000 peak-burst-size
768000 violate-action discard committed-data-rate 128000 committed-burst-size 384000 "
common 178 " group-id 1 direction uplink peak-data-rate 256000 peak-burst-size 768000
violate-action discard committed-data-rate 128000 committed-burst-size 384000 "
common 179 " group-id 2 direction downlink peak-data-rate 256000 peak-burst-size
768000 violate-action discard "
common 180 " group-id 2 direction uplink peak-data-rate 256000 peak-burst-size 768000
violate-action discard "
common 181 " #exit "
common 182 " rulebase cisco "
common 183 " billing-records egcdr "
common 184 " action priority 1 dynamic-only group-of-ruledefs GOR charging-action
qci1-GOR "
common 185 " action priority 11 dynamic-only ruledef qci1 charging-action qci1 "
common 186 " action priority 22 dynamic-only ruledef qci2 charging-action qci2 "
common 187 " action priority 66 dynamic-only ruledef qci6 charging-action qci6 "
common 188 " action priority 666 dynamic-only ruledef ipv6 charging-action ipv6 "
common 189 " egcdr threshold interval 3600 "
common 190 " egcdr threshold volume total 100000 "
common 191 " bandwidth default-policy bw_policy1 "
common 192 " #exit "
common 193 " rulebase cisco-CP1 "
common 194 " billing-records egcdr "

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
328
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

common 195 " action priority 1 dynamic-only group-of-ruledefs GOR-CP1 charging-action

qci1-GOR-CP1 "
common 196 " action priority 11 dynamic-only ruledef qci1 charging-action qci1 "
common 197 " action priority 22 dynamic-only ruledef qci2 charging-action qci2 "
common 198 " action priority 66 dynamic-only ruledef qci6-CP1 charging-action qci6-CP1
"
common 199 " action priority 666 dynamic-only ruledef ipv6 charging-action ipv6 "
common 200 " egcdr threshold interval 1000 "
common 201 " egcdr threshold volume total 100000 "
common 202 " bandwidth default-policy bw_policy1 "
common 203 " #exit "
common 204 " rulebase cisco-CP2 "
common 205 " billing-records egcdr "
common 206 " action priority 1 dynamic-only group-of-ruledefs GOR-CP2 charging-action
qci1-GOR-CP2 "
common 207 " action priority 11 dynamic-only ruledef qci1 charging-action qci1 "
common 208 " action priority 22 dynamic-only ruledef qci2 charging-action qci2 "
common 209 " action priority 66 dynamic-only ruledef qci6-CP2 charging-action qci6-CP2
"
common 210 " action priority 666 dynamic-only ruledef ipv6 charging-action ipv6 "
common 211 " egcdr threshold interval 1000 "
common 212 " egcdr threshold volume total 100000 "
common 213 " bandwidth default-policy bw_policy1 "
common 214 " #exit "
common 215 " rulebase default "
common 216 " #exit "
common 217 " credit-control group default "
common 218 " diameter origin endpoint PGW-Gy "
common 219 " diameter peer-select peer PGW-Gy-server "
common 220 " quota time-threshold 10 "
common 221 " diameter pending-timeout 150 deciseconds msg-type any "
common 222 " diameter session failover "
common 223 " trigger type rat qos sgsn serving-node "
common 224 " pending-traffic-treatment noquota pass "
common 225 " pending-traffic-treatment quota-exhausted buffer "
common 226 " timestamp-rounding floor "
common 227 " #exit "
common 228 " traffic-optimization-policy default "
common 229 " #exit "
common 230 " #exit "
common 231 " end "
common 232 " config "
common 233 " context ISP1-CP1 "
common 234 " apn xxx-CP1.com "
common 235 " ip context-name ISP1-CP1 "
common 236 " exit "
common 237 " apn yyy-CP1.com "
common 238 " ip context-name ISP1-CP1 "
common 239 " exit "
common 240 " end "
common 241 " config "
common 242 " context ISP1-CP2 "
common 243 " apn xxx-CP2.com "
common 244 " ip context-name ISP1-CP2 "
common 245 " exit "
common 246 " apn yyy-CP2.com "
common 247 " ip context-name ISP1-CP2 "
common 248 " exit "
common 249 " end "
exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
329
 Cisco Confidential - Limited Release
Multiple Control Plane Support on User Plane
Sample RCM Configuration

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
330
 Cisco Confidential - Limited Release

CHAPTER 44
N+2 UP Recovery
• Revision History, on page 331
• Feature Description, on page 331
• How It Works, on page 333
• Configuring N+2 UP Recovery, on page 347
• Monitoring and Troubleshooting, on page 349

Revision History
Revision History
Revision Details Release
First introduced. 21.19.n1

Feature Description
In accordance with 3GPP, the CP uses Sx-based failure detection which relies on Sx keep alive message
responses from the UP.
Using this approach, when the CP does not receive responses from the UP, it retransmits the Sx message a
configurable number of times before declaring the UP as down and initiating session tear downs. Depending
on the number of retries and the retry interval, the failure detection period can take more than 10 seconds for
a reliable determination that the UP is down. Until the Sx-path failure is detected at CP, the CP continues to
select the failed-UP and place new PDN-connections from UEs on the failed-UP.
In order to reduce the time it takes for the CP to detect that a UP is down, Cisco CPs can be configured to use
the Bidirectional Forwarding Detection (BFD) protocol (RFC 5883 - Bidirectional Forwarding Protocol
Detection (BFD) for Multihop Paths).
BFD uses significantly smaller retry periods (in the order of 200 msec) allowing for more rapid UP down
detection. It is in addition to the Sx keepalive mechanism for alternate deployment scenarios (e.g. 1:1 UP
redundancy).
NOTE: This feature is not dependent on Packet Flow Description (PFD) since PFD pushes common Day-N
configurations across the UPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
331
 Cisco Confidential - Limited Release
N+2 UP Recovery
Deployment Architecture

Deployment Architecture
This functionality can be enabled only in an "N+2" deployment scenario for UPs that process data sessions.
In this scenario, CPs are deployed as an active-standby pair. "N" number of active UPs can be deployed to
communicate with the CP. All of these UPs must be part of a specific, non-default, UP group.
NOTE: In N+2, all UPs are active. As such, this functionality only serves to improve data UP recovery times,
it is not a redundancy model. It is highly recommended that UPs processing IMS traffic only be deployed in
a 1:1 redundancy model.
BFD communications between the CP and UP requires the configuration of one additional loopback IP address
per CP/per UP.
Figure 14: BFD Monitoring in N+2 Deployment

Limitations
• BFD-based CP failure detection is not supported in this release. CP failures can continue to be detected
using the existing mechanism of Sx-path failure detection at the UP

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
332
 Cisco Confidential - Limited Release
N+2 UP Recovery
How It Works

NOTE: It is recommended that Sx-path failure timers be configured more aggressively to more quickly
prevent stale UP sessions.
• BGP monitoring on Gi/Gn interface (of UP) is not supported.
• Multi-BFD is not supported.
• BFD must be configured in the same context in which Sx is configured (Gn-side) on both the CP and
UP.

How It Works
The figure and the table that follow provide a high-level description of the session detach and re-attach process
when a UP is detected as down.
Figure 15: N+2 UP Recovery Flow

Table 15: N+2 UP Recovery Flow

Number Description
1 The CP detects a UP failure.
2 The CP sends UP detach session messages to the MME(s) with a cause code of Local-Detach.
3 The MMEs process the request(s) and detach the sessions.
4 The CP communicates with the AAA/PCRF/Charging infrastructure to detach the sessions.
5 The CP (active) communicate with the standby CP to checkpoint the UP detach.
6 UEs whose sessions were previously detached, re-attach to the MME.
7 The MME communicates with the CP to re-attach UE sessions.
8 The CP communicates with the AAA/PCRF/Charging infrastructure to re-attach the sessions.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
333
 Cisco Confidential - Limited Release
N+2 UP Recovery
Call Flows

Number Description
9 The CP completes the session re-attach process over the Sx interface with an alternate active UP.

Detailed detach and reattach on path failure flows for SAEGW CP/UP, P-GW CP/UP, S-GW CP/UP, and
GnGp GGSN CP/UP are in the sections that follow.

Call Flows
SAEGW Detach and Reattach on Path Failure
The figure and the table that follows describe the detach and re-attach on path failure process for SAEGW
CPs and UPs.
Figure 16: SAEGW CP/UP Detach and Re-attach on Path Failure Process

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
334
 Cisco Confidential - Limited Release
N+2 UP Recovery
SAEGW Detach and Reattach on Path Failure

Table 16: SAEGW CP/UP Detach and Re-attach on Path Failure Process

Number Description
1 UE data sessions are processed by an active SAEGW UP.
2 The active SAEGW CP monitors SAEGW UPs via BFD and Sx-Heartbeat messages.
3 The secondary CP also monitors SAEGW UPs via BFD.
4 The active and standby CPs detect a BFD failure on a UP before eNB detection (relays on Sx
timers (interval, retransmission, timeout)).
5 The BFD/VPNMGR on the active CP informs the Sx-demux process of a BFDDown event.
6 The Sx-demux process on the active CP initiates a path Failure notice to all Session Managers on
the CP.
7 All Session Managers initiate the process of detaching sessions by sending Delete-bearer-req
messages with a cause of Local-Detach to the MME. The detaches are initiated at a pre-defined
rate.
8 The MME sends Delete-bearer-resp messages back to the CP.
The MME does not page idle UEs with sessions being detached.
The MME sends E-RAB release messages to active UEs with sessions being detached.

9 The active CP releases the session release with the AAA server(s).
10 The active CP releases the session with the PCRF.
11 The active CP releases the session with the Charging infrastructure.
12 The active CP syncs session detach information with the secondary CP.
13 For UEs re-initiating their session(s), the MME sends a Create-session-request message to the
active CP.
The MME selects the CP based on load algorithm (DNS, local config etc.).

14 The active CP processes the session attach request with the AAA server(s).
15 The active CP processes the session attach request with the PCRF.
16 The active CP processes the session attach request with the Charging infrastructure.
17 The active CP sends a Sx Session Establishment Request message to an alternate active UP.
The CP selects the UP based on its load algorithm.

18 The UP sends a Sx Session Establishment Response message back to the CP.

19 The CP sends a Create-session-response message to the MME.
20 The active CP syncs information for the newly attached session with the secondary CP.
21 UE data sessions are now processed by the active SAEGW UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
335
 Cisco Confidential - Limited Release
N+2 UP Recovery
P-GW Detach and Reattach on Path Failure

P-GW Detach and Reattach on Path Failure

The figure and the table that follows describe the detach and re-attach on path failure process for P-GW CPs
and UPs.
Figure 17: P-GW CP/UP Detach and Re-attach on Path Failure Process

P-GW CP/UP Detach and Re-attach on Path Failure Process

Table 17: P-GW CP/UP Detach and Re-attach on Path Failure Process

Number Description
1 UE data sessions are processed by an active P-GW UP.
2 The active P-GW CP monitors P-GW UPs via BFD and Sx-Heartbeat messages.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
336
 Cisco Confidential - Limited Release
N+2 UP Recovery
S-GW Detach and Reattach on Path Failure

Number Description
3 The secondary CP also monitors P-GW UPs via BFD.
4 The active and standby CPs detect a BFD failure on a UP before eNB detection (relays on Sx
timers (interval, retransmission, timeout)).
5 The BFD/VPNMGR on the active CP informs the Sx-demux process of a BFDDown event.
6 The Sx-demux process on the active CP initiates a path Failure notice to all Session Managers on
the CP.
7 The S-GW initiates a db-req to the MME.
8 All Session Managers initiate the process of detach sessions by sending Delete-bearer-req messages
with a cause of Local-Detach to the MME. The detaches are initiated at a pre-defined rate.
9 The MME sends Delete-bearer-resp messages back to the CP.
The MME does not page idle UEs with sessions being detached.
The MME sends E-RAB release messages to active UEs with sessions being detached.

10 The S-GW forwards the db-resp to the PGW-C and removes it’s PDN session.
11 The active CP releases the session release with the AAA server(s).
12 The active CP releases the session with the PCRF.
13 The active CP releases the session with the Charging infrastructure.
14 The active CP syncs session detach information with the secondary CP.
15 For UEs re-initiating their session(s), the MME sends a Create-session-request message to the
active CP.
The MME selects the CP based on load algorithm (DNS, local config etc.).

16 The active CP processes the session attach request with the AAA server(s).
17 The active CP processes the session attach request with the PCRF.
18 The active CP processes the session attach request with the Charging infrastructure.
19 The active CP sends a Sx Session Establishment Request message to an alternate active UP.
The CP selects the UP based on its load algorithm.

20 The UP sends a Sx Session Establishment Response message back to the CP.

21 The CP sends a Create-session-response message to the MME.
22 The active CP syncs information for the newly attached session with the secondary CP.
23 UE data sessions are now processed by the active SAEGW UP.

S-GW Detach and Reattach on Path Failure

The figure and the table that follows describe the detach and re-attach on path failure process flow for S-GW
CPs and UPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
337
 Cisco Confidential - Limited Release
N+2 UP Recovery
S-GW Detach and Reattach on Path Failure

Figure 18: S-GW CP/UP Detach and Re-attach on Path Failure Process

Table 18: S-GW CP/UP Detach and Re-attach on Path Failure Process

Number Description
1 UE data sessions are processed by an active S-GW UP and an active PGW UP.
2 The active S-GW CP monitors S-GW UPs via BFD and Sx-Heartbeat messages.
3 The secondary S-GW CP also monitors S-GW UPs via BFD.
4 The active and standby S-GW CPs detect a BFD failure on the S-GW UP before eNB detection
(relays on Sx timers (interval, retransmission, timeout)).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
338
 Cisco Confidential - Limited Release
N+2 UP Recovery
GnGp GGSN Detach and Reattach on Path Failure

Number Description
5 The BFD/VPNMGR on the active S-GW CP informs the Sx-demux process of a BFDDown event.
6 The Sx-demux process on the active CP initiates a path Failure notice to all Session Managers on
the CP.
7 The S-GW CP initiates a db-req to the MME.
8 All Session Managers initiate the process of detach sessions by sending Delete-bearer-req messages
with a cause of Local-Detach to the MME. The detaches are initiated at a pre-defined rate.
9 The MME sends Delete-bearer-resp messages back to the S-GW CP.
The MME does not page idle UEs with sessions being detached.
The MME sends E-RAB release messages to active UEs with sessions being detached.

10 The active S-GW CP releases the session release with the PGW UP.
11 The PGW CP releases the session with the AAA server(s).
12 The PGW CP releases the session with the PCRF.
13 The PGW CP releases the session with the Charging infrastructure.
14 The active S-GW CP syncs session detach information with the secondary S-GW CP.
15 For UEs re-initiating their session(s), the MME sends a Create-session-request message to the
active S-GW CP.
The MME selects the CP based on load algorithm (DNS, local config etc.).

16 The active S-GW CP relays the Create-session-request message to the PGW CP

17 The PGW CP processes the session attach request with the AAA server(s).
18 The PGW CP processes the session attach request with the PCRF.
19 The PGW CP processes the session attach request with the Charging infrastructure.
20 The active S-GW CP exchanges Sx Session Establishment Request and Response messages with
an alternate active S-GW UP.
21 The active PGW CP exchanges Sx Session Establishment Request and Response messages with
an active PGW UP.
22 The PGW CP sends a Create-session-response message to the S-GW CP.
23 The S-GW CP sends a Create-session-response message to the MME.
24 The active S-GW CP syncs information for the newly attached session with the secondary S-GW
CP.
25 The S-GW CP and the complete the Modify Bearer Request procedure with the MME before UE
data can flow through the active UPs.

GnGp GGSN Detach and Reattach on Path Failure

The figure and the table that follows describe the detach and re-attach on path failure process flow for GnGp
GGSN CPs and UPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
339
 Cisco Confidential - Limited Release
N+2 UP Recovery
GnGp GGSN Detach and Reattach on Path Failure

Figure 19: GnGp GGSN CP/UP Detach and Re-attach on Path Failure Process

Table 19: GnGp GGSN CP/UP Detach and Re-attach on Path Failure Process

Number Description
1 UE data sessions are processed by an active GGSN UP.
2 The active GGSN CP monitors GGSN UPs via BFD and Sx-Heartbeat messages.
3 The secondary CP also monitors GGSN UPs via BFD.
4 The active and standby CPs detect a BFD failure on a UP before eNB detection (relays on Sx
timers (interval, retransmission, timeout)).
5 The BFD/VPNMGR on the active CP informs the Sx-demux process of a BFDDown event.
6 The Sx-demux process on the active CP initiates a path Failure notice to all Session Managers on
the CP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
340
 Cisco Confidential - Limited Release
N+2 UP Recovery
Additional N+2 Handling Scenarios

Number Description
7 All Session Managers initiate the process of detaching sessions by sending Delete-pdp-context-req
messages with no cause code to the SGSN. The detaches are initiated at a pre-defined rate.
8 The SGSN sends Delete-pdp-context-resp messages back to the CP.
The SGSN does not page idle UEs with sessions being detached.
The SGSN sends E-RAB release messages to active UEs with sessions being detached.

9 The active CP releases the session release with the AAA server(s).
10 The active CP releases the session with the PCRF.
11 The active CP releases the session with the Charging infrastructure.
12 The active CP syncs session detach information with the secondary CP.
13 For UEs re-initiating their session(s), the SGSN sends a Create-pdp-request message to the active
CP.
The SGSN selects the CP based on load algorithm (DNS, local config etc.).

14 The active CP processes the session attach request with the AAA server(s).
15 The active CP processes the session attach request with the PCRF.
16 The active CP processes the session attach request with the Charging infrastructure.
17 The active CP sends a Sx Session Establishment Request message to an alternate active UP.
The CP selects the UP based on its load algorithm.

18 The UP sends a Sx Session Establishment Response message back to the CP.

19 The CP sends a Create-pdp-context response message to the SGSN.
20 The active CP syncs information for the newly attached session with the secondary CP.
21 UE data sessions are now processed by the active GGSN UP.

Additional N+2 Handling Scenarios

Beyond the flows described in the previous sections, the following table provides a description of network
function (NF)/system behavior under various conditions with N+2 configured.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
341
 Cisco Confidential - Limited Release
N+2 UP Recovery
Additional N+2 Handling Scenarios

Table 20: N+2 Handling Scenarios

ID Scenario Handling Notes

1 Active UP crash Active CP detects Detection occurs within
BFD-failure with UP and the BFD timeout interval.
detaches sessions
CP Sx monitors BFD.
belonging to that UP.
Active CP propagates the
disconnects to standby CP
through SRP.
When UP returns to
active, it will re-associate
with the active CP.

2 Active CP crash Active CP switches over Standby CP starts sending

to standby CP. Sx-heartbeat upon failover
– no sessions are purged
Active UP monitors
by active UP.
Sx-heartbeat session for
both active and standby
CPs.
Active UP does not purge
sessions until ICSR
failover time is reached.

3 Standby CP crash Standby CP comes up and Sessions remain intact on

performs checkpoint with active CP and active UP.
active CP to recover
sessions
4 Network flaps between Active CP detects
active CP and active UP; BFD-Down for UP and
network between standby initiates session detach
CP and active UP remains processes and
alive disassociates UP.
Active CP propagates the
disconnects to standby CP
through SRP.
Active UP monitors
Sx-heartbeat with active
CP.
Active UP waits until
configured Sx-heartbeat
/path failure detection
timeout occurs (>SRP
switchover time) before
clearing sessions.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
342
 Cisco Confidential - Limited Release
N+2 UP Recovery
Additional N+2 Handling Scenarios

ID Scenario Handling Notes

5 Network flaps between Active UP detects Sx-path UPs delete the sessions
standby CP and active failure. due to Sx-heartbeat
UP; active CP and active timeout.
Active UP waits until
UP Sx-heartbeat also
configured Sx-heartbeat
down
/path failure detection
timeout occurs (>SRP
switchover time) before
clearing sessions.
Active CP detects
BFD-Down for UP and
initiates session detach
processes and
disassociates UP.

6 Network flaps between Standby CP operates

standby CP and active normally.
UP; Network between
Active CP-active is alive
active CP and active UP
and responds to heartbeat.
is alive
Active UP operates
normally.

7 Sx is not reachable, Active UP detects Sx-path Corner case that is treated

however BFD is failure. as Sx-path failure per
reachable. current behavior (before
Active UP waits until
N+2).
configured
Sx-heartbeat/path failure
detection timeout occurs
(>SRP switchover time)
before clearing sessions.
Active CP detects Sx-path
failure for UP and initiates
session detach processes
and disassociates UP.

8 ICSR link between active Upon becoming All service IPs advertised
and standby CPs goes dual-Active, standby CP by dual-Active standby
down and standby CP also sends message to active CP are with higher metric.
becomes active UP with higher metric.
(Dual-Active case)
9 BGP failure Gn side of No action is taken in
active UP relation to N+2.
10 BGP failure SGI side of No action is taken in
active UP relation to N+2.
11 SessMgr crashes on active Session recovery process
UP occurs on active UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
343
 Cisco Confidential - Limited Release
N+2 UP Recovery
Additional N+2 Handling Scenarios

ID Scenario Handling Notes

12 Sx-demux crashes on Sx-demux recovery
active UP process occurs on active
UP.
13 VPP crashes on active UP NPUMgr restarts the UP
resulting in BFD loss
triggering UP failure
detection.
Refer to Handling
information for IDs 1 and
5 in this table.

14 VPNMgr crashes on VPNMgr recovery

active UP process occurs on active
UP.
15 BFD crashes on active UP BFD recovery process
occurs on active UP.
16 Sx-demux crashes on Sx-demux recovery It is possible for a UP
active CP process occurs on active state change to occur
CP. during the Sx-demux
recovery on active CP
Sx-demux re-registers for
(e.g. UP restarts but still
BFD between CP and all
shows as active to CP post
UPs as part of recovery
recovery).
and rediscovers the state
of each UP. Condition detected as
follows:
Sx-demux recovers the
restart-timestamp from the • Sx-demux recovers
SessMgr. and CP detects either
UP restart timestamp
from Sx-heartbeat or
UP-failure.
• Based on this
information, active
CP initiates session
purging.

17 VPNMgr crashes on VPNMgr recovery

active CP process occurs on active
CP.
BFDregistration
information from
recovered from SCT on
active CP.
Active CP restarts BFD
with UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
344
 Cisco Confidential - Limited Release
N+2 UP Recovery
Double Failure Handling Scenarios

ID Scenario Handling Notes

18 BFD crashes on active CP BFD recovery process
occurs on active CP.
19 SessMgr crashes on active SessMgr recovery process
CP occurs on active CP.

Double Failure Handling Scenarios

N+2 double failure scenarios occur when there is a BFD failure followed by another event/failure. The handling
of such scenarios is described in the following table.

Table 21: N+2 Double Failure Scenario Handling

ID Scenario Handling Notes

1 Active CP fails while ICSR switchover occurs Impact:
session detaches are in between CPs.
If UP restarts on double
progress
Standby CP becomes failure, it will have no
active CP. sessions even though the
standby CP will have
Active CP detects UP
recovered the sessions.
failure via BFD.
These sessions are then
Active CP detects UP
cleaned as part of session
restart vis Sx-heartbeat.
replacement or session
disconnects from UEs.
If UP does not restart then
the CP-new-active clears
the sessions of the failed
UP.

2 Standby CP fails while Standby CP checkpoints

session detaches are in state information with the
progress Active CP.
Information pertaining to
deleted sessions is
invalidated from active
CP.

3 Active CP determines UP Once UP BFD down is

failure due to router flap; initially detected, all
Active CP receives UP sessions are detached.
BFD after initiating
session detaching

BFD Flapping and VPC

N+2 uses BFD to monitor the existence/viability of a network path between the session endpoints. By using
multihop BFD with loopback endpoints, the BFD session state functions as a proxy for the state of the system
to which it connects.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
345
 Cisco Confidential - Limited Release
N+2 UP Recovery
Sx-association Scenarios

However, a BFD session can go down, or bounce/flap, for reasons other than far-side system failure (e.g. due
to ARP storms or router misconfiguration). If the disruption is sufficiently severe and long lasting, it can cause
systems on both sides to detect BFD session failure even though both systems are functional.
Configuration adjustments can be made to help offset the occurrence of such events.
The following recommendations are offered based on the platform on which your NFs are deployed:
• VPC-SI: Adjust the BFD multihop-peer settings to increase the BFD detection time to 2-3 sec and the
number of retries correspondingly.
• VPC-DI: CF switchover and SF migration can interrupt BFD packet generation and processing for
multiple seconds. To prevent BFD session flaps when these events occur, BFD detection time for sessions
involving VPC-DI systems must be set to 5 seconds or longer.

Sx-association Scenarios
The following table provides information on associating and disassociating CPs and UPs when using N+2.

Table 22: N+2 Sx-association Scenarios

Scenario Mechanism(s)
Sx-disassociation from • Sx-demux to disable BFD monitoring with VPNMgr
UP to CP
• SAEGW-service is removed
• Sx-disassociation from UP

Adding UPs As part of Day-0:

• Add BFD loopback address for UP.
• Configurate BFD on CPs.
• Add UP Group and configure it for selection on CPs.

Removing UPs On CP, execute the CLI command to clear subscribers with IP address of UP and
keyword to block new sessions being placed on that UP.
• Verify that all the subscribers are torn down on UP.
• On the UP, execute the CLI command to disassociate from CP. This will
disassociate the UP from CP and CP will not choose this UP for further
sessions. Verify that all the sessions have been torn down.
• On CP, remove the UP from the UP Group.
• On CP, execute the CLI command to remove the UP from the UP Group
(this will also deregister the BFD monitoring of the UP).
• Disable the BFD configurations for monitoring at UP and at CP: no
monitor-group CLI command.

UP-initiated Sx-demux on CP starts processing the BFDUp and BFDDown notifications from
Sx-association VPNMGr.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
346
 Cisco Confidential - Limited Release
N+2 UP Recovery
N+2 and IP Addressing

UP-released Sx-demux on CP ignores the BFDUp and BFDDown notifications from VPNMgr.
Sx-association

N+2 and IP Addressing

Loopback IP Addresses
The following is true of BFD loopback addresses in relation to N+2:
• BFD loopback-IP-Address on the active CP and standby CP must be configured on Day-0.
• BFD operates between the active CP and active UP as well as between the standby CP and active UP.
As such, all three components must use unique BFD loopback-IP-addresses
• For each CP and UP, configured BFD loopback-IP-addresses must be different from the addresses used
for the Sx interfaces, and, in the case of the CPs must also be different from the addresses used for the
SRP interface.

IP Address Availability
With the N+2 deployment scenario, UEs may re-attach at a high rate (comparable to the detach rate). To
facilitate this process, UPs must have sufficient IP addresses available.
CUPS IP Pool Management includes the capability to provision UPs with "chunks" of addresses. The chunk
size and number of pools configured on the CP need to be increased proportionately so as to accommodate
the high rate of re-attachments from the CP to UP such that sessions do not get rejected by the UP due to
unavailability of IP addresses.
The potential re-attach rate can be roughly estimated by multiplying the number of Session Manager tasks
processing UP sessions by 1000 sessions/second.
Address capacity is determined by multiplying the size of the chunk (between 16 and 8192) and the number
of IP pools. Both configured on the CP.

Configuring N+2 UP Recovery

To configure N+2 UP Recovery:
1. Configure BFD on the CP and UP.

configure
context bfd_context_name
ip route static multihop bfd mhbfd_session_name local_endpoint_ip_address
remote_endpoint_ip_address
bfd-protocol
bfd multihop-peer dst_ip_address interval tx_interval min_rx
rx_interval multiplier value
#exit
#exit
NOTES:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
347
 Cisco Confidential - Limited Release
N+2 UP Recovery
Configuring N+2 UP Recovery

• bfd_ctx_name is the name of the context in which BFD is to be configured. This must be the same
context in which Sx is configured.
• mhbfd_session_name is a name for the BFD session route. Multiple session routes can be created,
one for each peer connection.
• local_endpoint_ip_address is the IPv4 or IPv6 address corresponding to the local interface in the
current context.
• remote_endpoint_ip_address is the IPv4 or IPv6 address corresponding to the remote BFD peer.
• If this route is being configured on the CP, then the remote address is that of the peer UP.
• If this route is being configured on the UP, then the remote address is that of the peer CP.

• dst_ip_address is the IPv4 or IPv6 address corresponding to the remote BFD peer. This must be the
same as the remote_endpoint_ip_address interface configured for the static multihop BFD route.
Multiple peers can be configured, one for each remote peer.
• interval tx_interval is the transmit interval (in milliseconds) between BFD packets.
• min_rx rx_interval is the minimum receive interval capability (in milliseconds) between BFD packets.
• multiplier value the multiplier value used to compute holddown.
• To determine the Detect Time (X), you can use the following calculation:
Detect Time (X) = interval tx_interval * multiplier value
The recommended value of Detect time (X) is 3 seconds for VPC-SI, and 5 seconds for VPC-DI.

2. Configure the BFD-loopback per context on the CP and UP.

configure
context monitor_ctx_name
monitor-protocols
monitor-group monitor_group_name protocol bfd
session-ctx session_ctx_name local-addr { ipv4_address | ipv6_address
} remote-address { ipv4_address | ipv6_address }
#exit
NOTES:
• Monitor_ctx_name is the name of the context in which BFD monitoring is to be configured. This
must be the same context in which Sx is configured.
• Monitor_group_name is the name of the group specifying the BFD monitoring parameters. Multiple
monitor-groups can be configured.
• Session_ctx_name is the name of the context containing the local interfaces over which BFD
monitoring will occur. This must be the same context in which Sx is configured.
• local-addr { ipv4_address | ipv6_address } is the IPv4 or IPv6 address corresponding to the local
interface in the specified context.
• remote-addr { ipv4_address | ipv6_address } is the IPv4 or IPv6 address corresponding to the remote
peer with which BFD monitoring will occur.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
348
 Cisco Confidential - Limited Release
N+2 UP Recovery
Monitoring and Troubleshooting

• If this monitor group is being configured on the CP, then the remote address is that of the UP
group.
• If this monitor group is being configured on the UP, then the remote address is that of the CP.

3. Configure the BFD-loopback (remote-IP) within a specific UP-group on the CP:

configure
user-plane-group up_group_name
peer-node-id { ipv4_address | ipv6_address } monitor-group-name
monitor_group_name
#exit
NOTES:
• up_group_name is the name of the UP group containing the data UPs for N+2 UP Recovery will be
supported.
• This cannot be the default group.
• This group should not contain UPs intended to support IMS/VoLTE.

• { ipv4_address | ipv6_address } is the IPv4 or IPv6 address of the Sx interface on an active UP that
will be part of the UP group. Multiple peer-nodes can be configured within the group. Note that the
Sx interface is a different interface from the one that will be used to monitor BFD.
• monitor_group_name is the name of the monitoring group the UP will be associated with.

Monitoring and Troubleshooting

Show Commands
show sx peers { full address peer_ip_address | wide }
show sx peers full address peer_ip_address
Displays the Monitor-related information for the specified peer (e.g. VPN context name, group name, and
state).
show sx peers wide
Displays "Monitor State" with the default state being "U" for UP, "D" for Down, and "N" for Not Applicable.
show sx-service statistics all

SNMP
The following SNMP traps can be used to monitor N+2 UP Recovery health:
• starBFDSessUp (starentTraps 1276)
• starBFDSessDown (starentTraps 1277)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
349
 Cisco Confidential - Limited Release
N+2 UP Recovery
SNMP

• starSxPathFailure (starentTraps 1382) – This trap has been updated to include a new cause code:
bfd-failure(8)
• starSxPathFailureClear (starentTraps 1383)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
350
 Cisco Confidential - Limited Release

CHAPTER 45
NAT Support
• Feature Summary and Revision History, on page 351
• Feature Description, on page 351
• Configuring NAT in CUPS, on page 353
• Monitoring and Troubleshooting, on page 354

Feature Summary and Revision History

Revision History
Revision Details Release

With this release, support for NAT64 is introduced. 21.20

First introduced. 21.19

This feature is not fully qualified in this release.

Feature Description
CUPS supports Network Address Translation (NAT) which allows you to configure network addresses. The
system can be configured to automatically forward data packets encapsulating the source IP or Source port
address of the UE with NAT IP address and NAT port.
The following list is the supported NAT combinations:
• NAT44 On Demand Many to One
• NAT44 On Demand One to One
• NAT64 On Demand Many to One
• NAT 64 On Demand One to One
• NAT44 Not On Demand Many to One
• NAT44 Not On Demand One to One

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
351
 Cisco Confidential - Limited Release
NAT Support
Limitations

• NAT64 Not On Demand Many to One

• NAT64 Not On Demand One to One

For supplemental information about NAT, see StarOS NAT Administration Guide.
NOTE: Not all features and/or functionality that are mentioned in StarOS NAT Administration Guide are
applicable in CUPS architecture.

Limitations
NAT support has the following limitations:
• Only NAT44 with many-to-one and on-demand mode is supported.
• All NAT pools are configured at respective User Plane on destination context.
• Charging action with CLI action deny in fw-and-nat policy and for flow-any-error charging action in
active-charging-service is not supported.
• Access-rules which are configured with "dynamic-only" and "static-and-dynamic" – rules from external
servers are not supported.
• Multiple IP support from same realm is not supported with this feature.
• Next hop forwarding in NAT pool is not supported.
• Port range in NAT pool is not supported.
• Skip private IP check CLI is not supported.
• RADIUS and Gy returned Fw-and-nat policy-based applying NAT policy is not supported.
• Bearer specific filters are not supported in access-ruledefs.
• Access-rules do not support trigger open-port port range config in fw-and-nat policy.
• NAT port recovery (fw-and-nat action) is not supported after SR/ICSR.
• NAT Re-assembly Timeout CLI is not supported in active-charging service. The generic context level
CLI on UP must be used instead.
• NAT fragmentation re-assembly failure is not supported due to open bugs in basic CUPS re-assembly.
• NAT flow-mapping timer is not supported
• For N:M redundancy, the NAT IP pools to be configured from RCM done as part of interface config for
each UP host and the pool name needs to be unique across all the active User Planes. This makes it
mandatory to use NAT Groups for all the pools so that the same NAT realm referred in fw-and-nat policy
can be applicable for all the User Planes.
• In case of N:M redundancy, the total number of NAT IP pools collectively configured on all UPs via
RCM must be as per the maximum limit (2000) of IP pools. The configuration in standby User Plane
fails if the cumulative total of all active UPs exceeds the maximum value.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
352
 Cisco Confidential - Limited Release
NAT Support
Configuring NAT in CUPS

Configuring NAT in CUPS

The relevant configuration of NAT is done at CP and pushed to UP. Only pool-related configuration is present
on User Plane.
For information on NAT-related CLI commands, refer to the StarOS NAT Administration Guide > NAT
Configuration chapter.
NOTE: Not all CLI commands and configurations mentioned in the StarOS NAT Administration Guide >
NAT Configuration chapter are applicable in CUPS architecture.

Sample Configurations
Control Plane
The following is a sample configuration required at Control Plane for enabling NAT in CUPS. This
configuration is pushed to User Plane during User Plane registration through PFD mechanism.

configure
active-charging service ACS
access-ruledef all
ip any-match = TRUE
#exit
access-ruledef udp
udp any-match = TRUE
#exit
access-ruledef tcp
tcp any-match = TRUE
#exit
access-ruledef icmp
icmp any-match = TRUE
#exit
fw-and-nat policy NatPolicy1
access-rule priority 1 access-ruledef tcp permit nat-realm NAT44_GRP1
access-rule priority 2 access-ruledef icmp permit nat-realm NAT44_GRP1
#access-rule priority 2 access-ruledef r2 permit bypass-nat
nat policy ipv4-only default-nat-realm NAT44_PUBLIC5
nat binding-record edr-format NBR port-chunk-allocation port-chunk-release
#exit

fw-and-nat policy NatPolicy2

access-rule priority 1 access-ruledef all permit nat-realm NAT44_PUBLIC1
#access-rule priority 2 access-ruledef r2 permit bypass-nat
nat policy ipv4-only
nat binding-record edr-format NBR port-chunk-allocation port-chunk-release
#exit

rulebase cisco
fw-and-nat default-policy NatPolicy1
flow end-condition normal-end-signaling session-end timeout edr NBR
#exit
#exit
end

User Plane
The following pool-related configuration is required at User Plane in ISP context.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
353
 Cisco Confidential - Limited Release
NAT Support
Monitoring and Troubleshooting

configure
context ISP1-UP
ip pool NAT44_PUBLIC1 118.118.0.0 255.255.0.0 napt-users-per-ip-address 2 on-demand
port-chunk-size 16 max-chunks-per-user 4 group-name NAT44_GRP1
ip pool NAT44_PUBLIC2 128.128.0.0 255.255.0.0 napt-users-per-ip-address 2 on-demand
port-chunk-size 16 max-chunks-per-user 4 group-name NAT44_GRP1
ip pool NAT44_PUBLIC3 208.208.0.0 255.255.0.0 napt-users-per-ip-address 2 on-demand
port-chunk-size 8 max-chunks-per-user 1 group-name NAT44_GRP2
ip pool NAT44_PUBLIC4 218.218.218.0 255.255.255.0 napt-users-per-ip-address 4 on-demand
port-chunk-size 32256 max-chunks-per-user 4 group-name NAT44_GRP2
ip pool NAT44_PUBLIC5 108.108.108.0 255.255.255.252 napt-users-per-ip-address 8064
on-demand port-chunk-size 8 max-chunks-per-user 2
end

Sample NAT Pool Related Configuration for Different NAT Pool Types

1-1 on-demand:
----------------------------
config
context ISP1-UP
ip pool NAT44_ipv4_1_1 108.108.108.0 255.255.255.0 nat-one-to-one on-demand nat-binding-timer
60
end

N-1 Not-on-demand:
------------------------
config
context ISP1-UP
ip pool NAT44_ipv4_N_1 21.189.128.0 255.255.255.0 napt-users-per-ip-address 2
max-chunks-per-user 2 port-chunk-size 8
end

1-1 Not-on-demand:
------------------------
config
context ISP1-UP
ip pool NAT44_ipv4_NOD_1_1 21.189.129.0 255.255.255.252 nat-one-to-one
end

Note In Control Plane configuration needs to be added along with one or more access ruledef mapped to any of the
required NAT Pool/Group configured in User Plane. For more information, see Ultra Packet Core CUPS
Control Plane Administration Guide.

Monitoring and Troubleshooting

Gathering NAT Statistics in CUPS
The following table lists the commands that can be used to gather NAT statistics. The first column lists what
statistics to gather and the second column lists the user plane command to use.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
354
 Cisco Confidential - Limited Release
NAT Support
Clear Commands

Statistics/Information Show Command

Information for all current subscribers who have either show subscribers user-plane-only full all
active or dormant sessions. Checks IP address
associated with subscriber. Also displays all the IP
addresses that are in use in a NAT realm.
Information on NAT subsystem statistics. show user-plane-service
statistics all

All NAT-related statistics. show user-plane-service

statistics nat all

All NAT Realm-related statistics. show user-plane-service

statistics nat nat-realm all

Statistics of all NAT IP pools in a NAT IP pool group. show user-plane-service statistics nat nat-realm
pool_name
Information on NAT bind records generated. show user-plane-service edr-format statistics all
Verifying association of fw-and-nat policy in APN show user-plane-service pdn-instance name name
on UP.
Verifying cofiguration of fw-an-nat policy on UP. show user-plane-service fw-and-nat policy all
Information on NAT bind records generated for port show user-plane-service rulebase name name
chunk allocation and release.
Information on access ruledef. show user-plane-service ruledef all
Verifying association of fw-and-nat policy in rulebase show user-plane-service rulebase name name
on UP.

Clear Commands
The following clear CLI commands are available in support of this feature:
• clear user-plane-service statistics nat nat-realm all
• clear user-plane-service statistics nat all

SNMP Traps for NAT Parameter Thresholds

The following SNMP traps for NAT parameter thresholds are supported in CUPS.

SNMP Traps Description

ThreshNATPortChunks Generated when NAT port chunk usage reaches
configured threshold limit
ThreshClearNATPortChunks Generated when NAT port chunk usage reaches
configured clear threshold limit.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
355
 Cisco Confidential - Limited Release
NAT Support
Bulk Statistics

SNMP Traps Description

ThreshNATPktDrop Generated when NAT packet drop reaches configured
threshold limit.
ThreshClearNATPktDrop Generated when NAT packet drop reaches configured
clear threshold limit.
ThreshIPPoolUsed Generated when the number of IPs used in the IP Pool
reaches configured threshold limit.
ThreshClearIPPoolUsed Generated when the number of IPs used in the IP Pool
reaches configured clear threshold limit.
ThreshIPPoolFree Generated when IP pool is free and threshold limit
reached.
ThreshClearIPPoolFree Generated when IP pool is used, and clear threshold
limit reached.
ThreshIPPoolAvail Generated when IP pool is available for next flow and
configured threshold reached.
ThreshClearIPPoolAvail Generated when IP pool is used, and configured
threshold is reached.

NOTE: The respective CLIs must be configured in the User Plane to enable these traps.

Bulk Statistics
Context Schema
Table 23: Context Schema

Variable Name Data Counter Description

Type Type

nat-total-flows Int64 Counter Total number of NAT44 and NAT64 flows

nat44-total-flows Int64 Counter Total number of NAT44 flows
nat64-total-flows Int64 Counter Total number of NAT64 flows
bypass-nat-total-flows Int64 Counter Total number of NAT44 and NAT64 Bypass NAT
flows
bypass-nat-ipv4-total-flows Int64 Counter Total number of NAT44 Bypass NAT flows
bypass-nat-ipv6-total-flows Int64 Counter Total number of NAT64 Bypass NAT flows
nat-current-flows Int64 Gauge Current number of NAT44 and NAT64 flows
nat44-current-flows Int64 Gauge Current number of NAT44 flows
nat64-current-flows Int64 Gauge Current number of NAT64 flows
bypass-nat-current-flows Int64 Gauge Current number of NAT44 and NAT64 Bypass NAT
flows

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
356
 Cisco Confidential - Limited Release
NAT Support
ECS Schema

Variable Name Data Counter Description

Type Type

bypass-nat-ipv4-current-flows Int64 Gauge Current number of NAT44 Bypass NAT flows

bypass-nat-ipv6-current-flows Int64 Gauge Current number of NAT64 Bypass NAT flows
sfw-total-rxpackets Int64 Counter Total number of packets received by the Service
sfw-total-rxbytes Int64 Counter Total number of bytes received by the Service
sfw-total-txpackets Int64 Counter Total number of packets transferred by the Service
sfw-total-txbytes Int64 Counter Total number of bytes transferred by the Service
sfw-total-injectedpkts Int64 Counter Total number of packets injected by the Service
sfw-total-injectedbytes Int64 Counter Total number of bytes injected by the Service
sfw-dnlnk-droppkts Int64 Counter Total number of downlink packets dropped by the
Service
sfw-dnlnk-dropbytes Int64 Counter Total number of downlink bytes dropped by the
Service
sfw-uplnk-droppkts Int64 Counter Total number of uplink packets dropped by the Service
sfw-uplnk-dropbytes Int64 Counter Total number of uplink bytes dropped by the Service

Note Schema is supported in User Plane for CUPS.

ECS Schema
Table 24: ECS Schema

Variable Name Data Counter Description

Type Type

nat-current-ipv4-pdn-subscribers Int32 Gauge Current number of NAT IPv4 PDN

Subscribers
nat-current-ipv6-pdn-subscribers Int32 Gauge Current number of NAT IPv6 PDN
Subscribers
nat-current-ipv4v6-pdn-subscribers Int32 Gauge Current number of NAT IPv4v6
PDN Subscribers
nat-total-ipv4-pdn-subscribers Int64 Counter Total number of NAT IPv4 PDN
Subscribers
nat-total-ipv6-pdn-subscribers Int64 Counter Total number of NAT IPv6 PDN
Subscribers
nat-total-ipv4v6-pdn-subscribers Int64 Counter Total number of NAT IPv4v6 PDN
Subscribers

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
357
 Cisco Confidential - Limited Release
NAT Support
NAT-realm Schema

Variable Name Data Counter Description

Type Type

nat-current-ipv4-pdn-subscribers-with-nat-ip Int32 Gauge Current number of NAT IPv4 PDN

Subscribers with NAT IP
nat-current-ipv6-pdn-subscribers-with-nat-ip Int32 Gauge Current number of NAT IPv6 PDN
Subscribers with NAT IP
nat-current-ipv4v6-pdn-subscribers-with-nat-ip Int32 Gauge Current number of NAT IPv4v6
PDN Subscribers with NAT IP
nat-total-ipv4-pdn-subscribers-with-nat-ip Int64 Counter Total number of NAT IPv4 PDN
Subscribers with NAT IP
nat-total-ipv6-pdn-subscribers-with-nat-ip Int64 Counter Total number of NAT IPv6 PDN
Subscribers with NAT IP
nat-total-ipv4v6-pdn-subscribers-with-nat-ip Int64 Counter Total number of NAT IPv4v6 PDN
Subscribers with NAT IP
nat-total-unsolicited-dwnlnk-pkts Int64 Counter Total number of unslolicited
downlink packets received
nat-total-icmp-hu-sent-for-dwnlnk-pkts Int64 Counter Total number of ICMP host
unreachable sent for downlink
packets

Note Schema is supported in User Plane for CUPS.

NAT-realm Schema
The NAT realms are configured in User Plane and statistics are stored per-context per-realm. These statistic
variables, both cumulative and snapshot, are available in the nat-realm schema.

Table 25: NAT-realm Schema

Variable Name Data Counter Description

Type Type

Vpnname String Info Context name.

Realmname String Info Realm name.
nat-rlm-bind-updates Int64 Counter Total interim AAA NBU sent.
nat-rlm-bytes-txferred Int64 Counter Total number of NAT44 and NAT64 bytes
transferred by realm (uplink + downlink).
nat-rlm-bytes-nat44-tx Int64 Counter Total number of NAT44 bytes transferred
by realm.
nat-rlm-bytes-nat64-tx Int64 Counter Total number of NAT64 bytes transferred
by realm.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
358
 Cisco Confidential - Limited Release
NAT Support
NAT-realm Schema

Variable Name Data Counter Description

Type Type

nat-rlm-ip-flows Int64 Counter Total number of NAT44 and NAT64 flows

used by the realm.
nat-rlm-nat44-flows Int64 Counter Total number of NAT44 flows processed
by realm.
nat-rlm-nat64-flows Int64 Counter Total number of NAT64 flows processed
by realm.
nat-rlm-ip-denied Int32 Counter Total number of NAT44 and NAT64 flows
denied NAT IP address.
nat-rlm-ip-denied-nat44 Int64 Counter Total number of NAT44 flows denied IP.
nat-rlm-ip-denied-nat64 Int64 Counter Total number of NAT64 flows denied IP.
nat-rlm-port-denied Int32 Counter Total number of NAT44 and NAT64 flows
denied ports.
nat-rlm-port-denied-nat44 Int64 Counter Total number of NAT44 flows denied
ports.
nat-rlm-port-denied-nat64 Int64 Counter Total number of NAT64 flows denied
ports.
nat-rlm-memory-denied Int64 Counter Total number of NAT44 and NAT64 flows
denied memory.
nat-rlm-memory-denied-nat44 Int64 Counter Total number of NAT44 flows denied
memory.
nat-rlm-memory-denied-nat64 Int64 Counter Total number of NAT64 flows denied
memory.
nat-rlm-ttl-ips Int32 Gauge Total number of NAT public IP addresses,
per context per NAT realm. Is a static
value.
nat-rlm-ips-in-use Int32 Gauge Total number of NAT IP addresses
currently in use, per context per NAT
realm.
nat-rlm-current-users Int32 Gauge Total number of subscribers currently
using the NAT realm.
nat-rlm-ttl-port-chunks Int32 Gauge Total number port-chunks, per context per
NAT realm. Is a static value.
nat-rlm-chunks-in-use Int32 Gauge Total number of port-chunks currently in
use, per context per NAT realm.
nat-rlm-port-chunk-size Int32 Gauge Size of the port chunk in the NAT realm.
nat-rlm-port-chunk-average-usage-tcp Int32 Gauge Average TCP port usage in the allocated
TCP ports, i.e. out of allocated TCP ports
how many got used. Not percentage value.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
359
 Cisco Confidential - Limited Release
NAT Support
EDRs

Variable Name Data Counter Description

Type Type

nat-rlm-port-chunk-average-usage-udp Int32 Gauge Average UDP port usage in the allocated

UDP ports, i.e. out of allocated UDP ports
how many got used. Not percentage value.
nat-rlm-port-chunk-average-usage-others Int32 Gauge Average other (ICMP or GRE) port usage
in the allocated other ports, i.e. out of
allocated ‘other’ ports how many got used.
Not percentage value.
nat-rlm-max-port-chunk-subs Int64 Counter Total number of subscribers who used
maximum number of port chunks.
nat-rlm-max-port-chunk-used Int32 Counter Maximum port chunks used.
nat-rlm-max-cur-port-chunk-subs Int64 Gauge Current number of subscribers using
maximum number of port chunks.
nat-rlm-max-cur-port-chunk-used Int32 Gauge Maximum port chunks used by active
subscribers.

EDRs
The following NAT-specific attributes are supported in regular EDRs:
• sn-nat-subscribers-per-ip-address: Subscriber(s) per NAT IP address
• sn-subscriber-nat-flow-ip: NAT IP address of NAT-enabled subscribers
• sn-subscriber-nat-flow-port: NAT port number of NAT-enabled subscribers

Sample EDR
#sn-start-time,sn-end-time,ip-protocol,ip-subscriber-ip-address,ip-server-ip-address,sn-subscriber-port,sn-server-port,
sn-nat-ip,sn-nat-port-block-start,sn-nat-port-block-end,sn-subscriber-nat-flow-ip,sn-subscriber-nat-flow-port,sn-nat-realm-name,
sn-nat-subscribers-per-ip-address,sn-nat-binding-timer,sn-nat-gmt-offset,sn-nat-port-chunk-alloc-dealloc-flag,sn-nat-port-chunk-alloc-time-gmt,
sn-nat-port-chunk-dealloc-time-gmt,sn-nat-no-port-packet-dropped,sn-closure-reason
02/18/2020 12:11:11:630,02/18/2020
12:11:11:632,1,192.168.0.1,40.40.40.2,0,0,,,,128.128.0.4,1024,,2,,,,,,0,0
02/18/2020 12:11:08:672,02/18/2020
12:11:09:671,6,192.168.0.1,40.40.40.2,1001,3000,,,,128.128.0.4,1034,,2,,,,,,0,0
02/18/2020 12:11:14:499,02/18/2020
12:11:14:499,17,192.168.0.1,40.40.40.2,1001,3000,,,,108.108.108.1,1025,,8064,,,,,,0,0

NAT Binding Records

Whenever a NAT IP address or NAT port-chunk is allocated/deallocated to/from a subscriber, NAT Binding
Records (NBR) can be generated. Generation of NBRs is configurable in the Firewall-and-NAT policy
configuration.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
360
 Cisco Confidential - Limited Release
NAT Support
Sample NBR

Sample NBR
#sn-start-time,sn-end-time,ip-protocol,ip-subscriber-ip-address,ip-server-ip-address,sn-subscriber-port,
sn-server-port,sn-nat-ip,sn-nat-port-block-start,sn-nat-port-block-end,sn-subscriber-nat-flow-ip,sn-subscriber-nat-flow-port,
sn-nat-realm-name,sn-nat-subscribers-per-ip-address,sn-nat-binding-timer,sn-nat-gmt-offset,sn-nat-port-chunk-alloc-dealloc-flag,
sn-nat-port-chunk-alloc-time-gmt,sn-nat-port-chunk-dealloc-time-gmt,sn-nat-no-port-packet-dropped,sn-closure-reason
,,,192.168.0.1,,,,128.128.0.4,1024,1039,,,NAT44_PUBLIC2,2,60,+0530,1,02/18/2020 06:41:08,,,
,,,192.168.0.1,,,,108.108.108.1,1024,1031,,,NAT44_PUBLIC5,8064,60,+0530,1,02/18/2020
06:41:14,,,
,,,192.168.0.1,,,,128.128.0.4,1024,1039,,,NAT44_PUBLIC2,2,60,+0530,0,02/18/2020
06:41:08,02/18/2020 06:42:12,,
,,,192.168.0.1,,,,108.108.108.1,1024,1031,,,NAT44_PUBLIC5,8064,60,+0530,0,02/18/2020
06:41:14,02/18/2020 06:44:24,,

Packet Drop EDR

Sample Packet Drop EDR
#sn-nat-no-port-packet-dropped,sn-start-time,sn-end-time,sn-subscriber-imsi
2,03/13/2020 08:28:24,03/13/2020 08:28:54,123456789012345

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
361
 Cisco Confidential - Limited Release
NAT Support
Sample Packet Drop EDR

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
362
 Cisco Confidential - Limited Release

CHAPTER 46
NAT ALG Support
• Feature Summary and Revision History, on page 363
• Feature Description, on page 363
• Components of Session Initiation Protocol ALG, on page 364
• How it Works, on page 366
• NAT FW Processing, on page 368
• Configuring NAT ALG, on page 369
• Monitoring and Troubleshooting, on page 374

Feature Summary and Revision History

Revision History
Revision Details Release

This feature is fully qualified in this release. 21.20.0

First introduced. 21.19.0

This feature is not fully qualified in this release.

Feature Description

Note This feature is not fully qualified in this release.

NAT performs translation service on any Transmission Control Protocol/User Datagram Protocol (TCP/UDP)
traffic that doesn’t carry source and/or destination IP addresses in application data stream. These protocols
include:
• HTTP
• Trivial File Transfer Protocol (TFTP)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
363
 Cisco Confidential - Limited Release
NAT ALG Support
Components of Session Initiation Protocol ALG

• Telnet
• Archie
• Finger
• Network Time Protocol (NTP)
• Network File System (NFS)
• Remote login (rlogin)
• Remote shell protocol (RSH)
• Remote copy protocol (RCP)

The following specific protocols have the IP address information within the payload. These protocols require
the support of an Application Level Gateway (ALG) for translation services.
• FTP
• H323
• Session Initiation Protocol (SIP)
• Session Description Protocol (SDP)
• TFTP
• RTSP
• Point-to-Point Tunneling Protocol (PPTP)

Limitations
NAT64 to v4 translation for H323 is not supported.

Components of Session Initiation Protocol ALG

The following block diagram shows all the components that support SIP ALG for NAT or Firewall. The
ALG-CORE and SIP APP are the new components. The other components are existing one which requires
enhancements.

Note This example is specific to the SIP ALG, similar component is applicable for all other protocols in the document.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
364
 Cisco Confidential - Limited Release
NAT ALG Support
Components of Session Initiation Protocol ALG

Figure 20: Components of Session Initiation Protocol (SIP) ALG

Table 26: Component and Functionality

Component Function

ALG-CORE • Interacts with the NAT/FW to

create/modify/clear the pinholes.
• ALG-CORE has the logic to store the pinhole
information inside HA CLP. (defines a new
pointer to structure called sip_alg_info).
• ALG-CORE processes messages from SIPAPP
based on the state and event it received.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
365
 Cisco Confidential - Limited Release
NAT ALG Support
How it Works

Component Function

SIP APP • New functionality logic in each per

request/response callback.
• New data structures to maintain call/session
related information’s (based on stacks
callCb/TransactionCb data structures).
• Defines some generic UMM structures for
sip/H.323, to interact with the ALG-CORE.
• Do the encoding of the SIP message, that is
private IP to public IP ...from the information
returned by the ALG-CORE.

DC-SIP DC-SIP is a full-blown sip stack, which parses the sip

messages, maintains the transactions and call states.
For SIP-ALG functionality the DC-SIP acts as
B2BUA. Following are the functionalities DC-SIP
stack provides:
• Message parsing
• Transaction management
• Call management
• Message encoding
• Call back per request/response type.

The Socket Stub is the component that receives/sends packet from/to NAT/FW.
NAT/FW sends/receives the SIP packets to socket stub and it also provides the generic APIs to interact with
ALG-CORE.

How it Works
Some of network applications exchanges the IP/Port information of server/client as part of payload. The server
or client uses that exchanged IP/Port information to create new flows. As part of NAT ALGs, the server or
client extracts that IP/Port info and allow those flows dynamically through pinholes.
In case of NAT, the server or client does the IP and transport level translations. The NAT IP and NAT Port
replace the private source IP and source Port and conversely. But the sending application may not be aware
of these translations since these translations are transparent.
For example, FTP NAT ALG function interprets the 'PORT' and 'PASV reply' messages. NAT translates the
same in the payload so that the FTP happens transparently through the NAT.
NAT layer supports NAT 44 translation and NAT 64 translation. The NAT also supports 1:1 On demand
NAT translation and Many:1 NAT translation.
Following are supported for each of the ALGs:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
366
 Cisco Confidential - Limited Release
NAT ALG Support
FTP

• NAT 44 1:1 On demand NAT translation

• NAT 44 Many:1 NAT translation
• NAT 64 1:1 On demand NAT translation
• NAT 64 Many:1 NAT translation

FTP
FTP is a TCP-based protocol and uses two flows one is for control messages another one for data/file transfer.
FTP uses PORT and PASSIVE reply commands to exchange data flow parameters. These commands carry
IP and Port information as part of the pay load.

RTSP
RTSP is a TC-based real time streaming protocol having different methods to control real-time media transfer.
The control messages are having Port information embed, which is to transfer the media.

PPTP
Point-to-Point Tunneling Protocol (PPTP) allows the tunneling for Point to Point Protocol (PPP) through an
IP network. PPTP uses an enhanced GRE (Generic Routing Encapsulation) to carry PPP packets. PPTP
exchanges IP or port-specific information over its control connection and that information is to transfer the
data over tunnel.

SIP
SIP is an application-layer control protocol. SIP can establish, modify, and terminate multimedia sessions
(conferences) such as Internet telephony calls. SIP is based on a request/response transaction model. Each
transaction consists of a request that invokes a method, or function, on the server and at least one response.
These requests and responses have client and server IP and port information. The SDP message bodies for
describing multimedia sessions (that maybe present in SIP requests and responses) also has the IP and port
information embedded in them.
For the transmission of media streams (voice, video) the SDP payload carried in SIP messages typically
employs the Real-time Transport Protocol (RTP). The SIP ALG intercepts all the SIP communication and
translates the private IP and port in the payload to NAT IP and Port.

TFTP
Trivial File Transfer Protocol (TFTP) is an application layer protocol for File Transfers. Due to its simple
mechanism, many Embedded Systems uses this protocol to download images or files from the server. It’s a
UDP-based protocol. TFTP L7 payload doesn’t contain IP or Port information but requires the pinholes to
allow the Downlink initiated data flow.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
367
 Cisco Confidential - Limited Release
NAT ALG Support
H323

H323
H323 is a set of protocol specifications that can establish, modify, and terminate multimedia sessions such as
Internet telephony calls. Protocols involved in successful multimedia session are RAS, H225, H245, and
media protocols (RTP, RTCP). RAS protocol is for communication between H323 Gatekeeper and the terminal.
This communication helps to locate the other terminal to which it wants to communicate. H225 and H245
communicates between the terminals for session establishment, capability exchange, and media parameters
exchange. The H245 messages have the details of the media channel in which the multimedia communication
is going to take place. IP and Port information is present in the RAS, H225 and H245 messages. H323 ALG
intercepts all the H323 communication and translates the private IP and port in the payload to NAT IP and
Port.

NAT FW Processing
After receiving the key for processing the packets, the ECS framework creates flows with 5-tuple:
• Source IP
• Source port
• Protocol
• Destination IP
• Destination port

If it’s the first packet with a given 5-tuple, then a NAT/FW rule match applies to check if the packet is
acceptable or not. If packet is acceptable, then leads to a flow is creation.
Configuration of the NAT realm (NAT IP) is part of the rules. The NAT realm applicable for a flow is from
the rule-definition that matches the packet
Rule configuration happens are based on well-known server addresses/port numbers. For example, the FTP
service with port 21, SIP service with port 5060.
So, any FTP control session or SIP control session to well-known servers/port numbers finds a matching
firewall rule. However, it may not be possible to configure rules for media flows (child flows) that are
dynamically based on the control signaling.
In case of FTP data or SIP media packet, the NAT/FW rule definition match fails and drops the packets.
Another requirement is the control signaling and the corresponding media connection to use the same NAT
realm. Same NAT IP address applies for control and media.
Even if the child flow (media connection) finds a matching NAT/FW rule. The child flow uses the NAT realm
configuration for that rule, which isn’t correct. The media flows should be using the same NAT realm that is
applicable for the control connection.
So, the child flows even if there’s no matching rule uses the same NAT realm that was for the control
connection. In order to achieve the flow, create the pinholes based on the signaling messages. A pinhole
contains subset of 5-tuple information.
Pinholes are to allow the traffic without doing any rule match (bypass rule match). The NAT realm is associated
with the pinholes. Allows any traffic matching the pinholes and the NAT realm specified in the pinhole applies
for noting the packets.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
368
 Cisco Confidential - Limited Release
NAT ALG Support
Uplink Packet Processing

In case of many-to-one NAT, the NAT allows the downlink packets only if there’s an active NAT binding.
There are many services (SIP for example) where the remote end wants to initiate connections (incoming
call). Under such conditions, to allow downlink packets the ALG needs to create required NAT bindings and
associate with the pinholes by parsing signaling messages.
Following explains the uplink and downlink packet processing:

Uplink Packet Processing

Refer to the following points for the uplink packet processing.
• On receiving any uplink packet, comparison takes place against existing 5-tuple flows.
• If a matching flow exists (5-tuple match), the NAT binding that is associated with the flow applies on
the packet.
• If no flow exists, then a pinhole lookup happens to check if there are any pinholes opened for this flow.
• If pinhole exists, then the NAT binding associated with the pinhole applies on the packet.
• If no pinhole exists, then rule match determines the NAT information for that flow. If no matching rule
exists, the packet drops.

In case of outgoing SIP requests, the SIP message associates with the destination port as 5060. So, configure
a rule with destination port as 5060 for identifying SIP traffic. The corresponding NAT realm configured for
the rule gets applied on the SIP request.
Any pin holes based on the requests should have NAT bindings associated with them. This NAT bindings
allocation is from the NAT realm that was for processing the request.

Downlink Packet Processing

Refer to the following points for the uplink packet processing.
• The downlink packets pass only if an active NAT binding exists. If the binding-look up fails, then the
packet drops.
• If the binding lookup succeeds, the packet undergoes initial flow match processing same as an uplink
packet processing.
• However, in case of downlink packets, no rule match happens for a packet from on a many-to-one NAT
IP. The packet passes only if there’s matching flow or a matching pinhole otherwise it drops. If a pinhole
exists, then the NAT binding with the pinhole applies on that flow.
• In case of one-to-one NAT, even if there’s no pinhole, rule match happens, and packet passes if a matching
rule is there. The NAT realm that receives the packet applies for that downlink flow.

Configuring NAT ALG

Following are the commands to configure the NAT ALG.
configure
active-charging service cecs_service_name

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
369
 Cisco Confidential - Limited Release
NAT ALG Support
Sample Configuration for FTP NAT ALG

firewall nat-alg { default | no } { ftp | pptp | rtsp | sip |

h323 }
end
NOTES:
• default: Configures this command with the default setting for the specified parameter.
• no: Disables all/ or the specified NAT ALG configuration. When disabled, the ALG(s) will not do any
payload translation for NAT calls.
• ftp: Enables/disables File Transfer Protocol (FTP) NAT ALG.
• pptp: Enables/disables Point-to-Point Tunneling Protocol (PPTP) NAT ALG.
• rstp: Enables/disables Real Time Streaming Protocol (RTSP) ALG.
• sip: Enables/disables Session Initiation Protocol (SIP) NAT ALG.
• h323: Enables/disables H323 NAT ALG.

Configuration for Many to One and One to Many

Many to one configuration on the User Plane.
ip pool NAT44_PUBLIC4 218.218.218.0 255.255.255.0 napt-users-per-ip-address 4 group-name
NAT44_GRP2 on-demand max-chunks-per-user 4 port-chunk-size 32256

One to One configuration on the User Plane.

ip pool NAT44_PUBLIC4 218.218.218.0 255.255.255.0 nat-one-to-one on-demand group-name
NAT44_GRP1

Sample Configuration for FTP NAT ALG

In order to route the packets to the FTP ALG on Control Plane, Configure the following FTP routing rule.
Config
active-charging service acs
ruledef rt_ftp-control
tcp either-port = 21
rule-application routing
multi-line-or all-lines
#exit
ruledef rt_ftp-data
tcp either-port = 20
rule-application routing
multi-line-or all-lines
#exit
access-ruledef SFW_HTTP
ip any-match = TRUE
#exit
access-ruledef all
ip any-match = TRUE
#exit
access-ruledef ipv6_nat
ip server-ipv6-network-prefix = 64:ff98::/96
#exit
rulebase prepaid
route priority 14 ruledef rt_ftp-data analyzer ftp-data
route priority 15 ruledef rt_ftp-control analyzer ftp-control

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
370
 Cisco Confidential - Limited Release
NAT ALG Support
Sample Configuration for RTSP NAT ALG

#exit
fw-and-nat policy nat_policy1
access-rule priority 1 access-ruledef ipv6_nat permit nat-realm NAT44_GRP1
access-rule priority 10 access-ruledef SFW_HTTP permit nat-realm NAT44_GRP1
access-rule priority 100 access-ruledef all permit nat-realm NAT44_GRP1
nat policy ipv4-and-ipv6
#exit
firewall nat-alg ftp ipv4-and-ipv6
#exit

Sample Configuration for RTSP NAT ALG

Following are the sample configuration for RTSP NAT ALG:
Config
active-charging service acs
ruledef rtsp-pkts
tcp src-port = 554
rule-application routing
#exit
ruledef rtsp-pkts1
tcp dst-port = 554
rule-application routing
#exit
access-ruledef SFW_HTTP
ip any-match = TRUE
#exit
access-ruledef prefix1
ip server-ipv6-network-prefix = 64:ff98::/96
#exit
rulebase cisco
tcp 2msl-timeout 20
tcp mss 1300 limit-if-present
route priority 105 ruledef rtsp-pkts analyzer rtsp
route priority 106 ruledef rtsp-pkts1 analyzer rtsp
rtp dynamic-flow-detection
fw-and-nat default-policy nat_policy1
#exit
fw-and-nat policy nat_policy1
access-rule priority 1 access-ruledef prefix1 permit nat-realm NAT44_GRP1
access-rule priority 10 access-ruledef SFW_HTTP permit nat-realm NAT44_GRP1
nat policy ipv4-and-ipv6
#exit
firewall nat-alg rtsp ipv4-and-ipv6

Sample Configuration for PPTP NAT ALG

Following are the sample configuration for PPTP NAT ALG:
configure
active-charging service ACS
ruledef pptp-route
tcp either-port = 1723
rule-application routing
multi-line-or all-lines
exit
rulebase cisco
route priority 1 ruledef pptp-route analyzer pptp
#exit
#exit
access-ruledef all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
371
 Cisco Confidential - Limited Release
NAT ALG Support
Sample Configuration for TFTP NAT ALG

ip any-match = TRUE
#exit
access-ruledef ipv6_nat
ip server-ipv6-network-prefix = 101:101::/96
#exit
rulebase cisco
route priority 1 ruledef pptp-route analyzer pptp
fw-and-nat default-policy nat_policy1
#exit
fw-and-nat policy nat_policy1
access-rule priority 1 access-ruledef ipv6_nat permit nat-realm NAT44_GRP1
access-rule priority 100 access-ruledef all permit nat-realm NAT44_GRP1
nat policy ipv4-and-ipv6
#exit
firewall nat-alg pptp ipv4-and-ipv6
#exit

Sample Configuration for TFTP NAT ALG

Following are the sample configuration for NAT44 on Control Plane:
configure
active-charging service ACS
ruledef rt_tftp
udp either-port = 69
rule-application routing
multi-line-or all-lines
exit
rulebase cisco
route priority 1 ruledef rt_tftp analyzer tftp
#exit
#exit

Following are the sample configuration for NAT64 on Control Plane:

conf
active-charging service ACS
ruledef rt_tftp
udp either-port = 69
rule-application routing
multi-line-or all-lines
exit
access-ruledef all
ip any-match = TRUE
exit
access-ruledef ipv6_nat
ip server-ipv6-network-prefix = 64:ff98::/96
exit
rulebase cisco
route priority 1 ruledef rt_tftp analyzer tftp
fw-and-nat default-policy nat_policy
#exit
end
conf
context ISP1
ip pool NAT44_PVT1 172.16.0.0 255.255.0.0 private 0 group-name NAT44_GRP1
ip pool NAT44_PVT4 10.168.0.0 255.255.0.0 private 0 group-name NAT44_GRP1
end
conf
context ISP1
apn cisco.com
ip address pool name NAT44_GRP1
fw-and-nat policy nat_policy1

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
372
 Cisco Confidential - Limited Release
NAT ALG Support
Sample Configuration for H323 NAT ALG

exit
end
configure
active-charging service ACS
fw-and-nat policy nat_policy1
access-rule priority 1 access-ruledef ipv6_nat permit nat-realm NAT44_GRP1
access-rule priority 10 access-ruledef all permit nat-realm NAT44_GRP1
nat policy ipv4-and-ipv6
end

Sample Configuration for H323 NAT ALG

Following are the sample configuration for H323 NAT ALG:
configure
active-charging service ACS
ruledef h323
udp dst-port = 1719
rule-application routing
#exit
ruledef h323_multi
udp dst-port = 1718
rule-application routing
#exit
ruledef h323_tcp
tcp dst-port = 1720
rule-application routing
#exit
rulebase cisco
route priority 6 ruledef h323 analyzer h323
route priority 7 ruledef h323_tcp analyzer h323
route priority 8 ruledef h323_multi analyzer h323
rtp dynamic-flow-detection
fw-and-nat default-policy nat_policy1
#exit
fw-and-nat policy nat_policy1
access-rule priority 100 access-ruledef all permit nat-realm NAT44_GRP1
nat policy ipv4-and-ipv6
#exit
firewall nat-alg h323 ipv4-only
#exit

Sample Configuration for SIP NAT ALG

Following are the sample configuration for SIP NAT ALG:
conf
active-charging service service_1
ruledef sipalg
udp dst-port = 5060
rule-application routing
#exit
ruledef sipalg_tcp
tcp dst-port = 5060
rule-application routing
#exit
access-ruledef server2
ip dst-address = 192.168.10.40/32
#exit
access-ruledef nat64
ip server-ipv6-network-prefix = cccc:1111::/96

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
373
 Cisco Confidential - Limited Release
NAT ALG Support
Monitoring and Troubleshooting

ip any-match = TRUE
#exit
#exit
rulebase base_1
route priority 1 ruledef sipalg analyzer sip advanced description advanced
route priority 2 ruledef sipalg_tcp analyzer sip advanced description advanced
rtp dynamic-flow-detection
fw-and-nat default-policy fw1
#exit
fw-and-nat policy fw1
access-rule priority 2 access-ruledef server2 permit nat-realm natPool
access-rule priority 3 access-ruledef nat64 permit nat-realm natPool
nat policy ipv4-and-ipv6
#exit
firewall nat-alg sip ipv4-and-ipv6
#exit
#exi

Monitoring and Troubleshooting

This section provides information on CLI commands that are available for monitoring and troubleshooting
for NAT ALG feature in CUPS.

Show Commands and/or Outputs

This section provides information about show CLI commands that are available in support of NAT ALG
feature in CUPS.
• show user-plane-service statistics analyzer name rtsp: Use this command to view RTSP-related
statistics.
RTSP Session Stats:
Total Uplink Bytes: 844 Total Downlink Bytes: 1440
Total Uplink Pkts: 10 Total Downlink Pkts: 6
Uplink RTP Bytes: 8 Downlink RTP Bytes: 2851524
Uplink RTP Pkts: 2 Downlink RTP Pkts: 2741
Uplink Retry Bytes: 0 Downlink Retry Bytes: 0
Uplink Retry Pkts: 0 Downlink Retry Pkts: 0
RTSP Sessions: 1

• show user-plane-service statistics analyzer name rtp: Use this command to view RTP-related statistics.
RTP Session Stats:
Total Uplink Bytes: 8 Total Downlink Bytes: 2851524
Total Uplink Pkts: 2 Total Downlink Pkts: 2741

FastPath Statistics :
Total FP Flows: 1
Total Uplink FP Bytes: 0 Total Downlink FP Bytes: 2850497
Total Uplink FP Pkts: 0 Total Downlink FP Pkts: 2740

• show user-plane-service statistics analyzer name rtcp: Use this command to view RTCP-related
statistics.
RTCP Session Stats:
Total Uplink Bytes: 804 Total Downlink Bytes: 728
Total Uplink Pkts: 16 Total Downlink Pkts: 13

• show user-plane-service statistics analyzer name ftp: Use this command to view FTP-related statistics.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
374
 Cisco Confidential - Limited Release
NAT ALG Support
Monitoring and Troubleshooting

FTP Session Stats:

Current Control Sessions: 1 Current Data Sessions: 1
Total Control Sessions: 1 Total Data Sessions: 3
Uplink Control Bytes: 190 Downlink Control Bytes: 544
Uplink Control Pkts: 23 Downlink Control Pkts: 15
Uplink Data Bytes: 6733 Downlink Data Bytes: 12444
Uplink Data Pkts: 5136 Downlink Data Pkts: 14
Uplink Error Bytes: 0 Downlink Error Bytes: 0
Uplink Error Pkts: 0 Downlink Error Pkts: 0
Request Succeed: 14 Request Failed: 0
Unknown Requests: 0 Unknown Responses: 0
Uplink Bytes Retrans: 0 Downlink Bytes Retrans: 0
Uplink Pkts Retrans: 0 Downlink Pkts Retrans: 0
RETR commands: 2 STOR commands: 1
Unknown packets received: 0
Data packet received without control connection: 0
Invalid packets: 0
Packets that could not be parsed: 0

FastPath Statistics :
Total FP Control Flows: 0
Total FP Data Flows: 3
Uplink : Downlink :
Total FP Control Pkts : 0 Total FP Control Pkts : 0
Total FP Control Bytes : 0 Total FP Control Bytes: 0
Total FP Data Pkts : 0 Total FP Data Pkts : 0
Total FP Data Bytes : 0 Total FP Data Bytes: 0

• show user-plane-service statistics analyzer name pptp: Use this command to view PPTP-related
statistics.
PPTP Session Stats:
Total Uplink Bytes: 0 Total Downlink Bytes: 0
Total Uplink Pkts: 0 Total Downlink Pkts: 0
Total GRE Sessions: 0 Invalid PPTP Pkts: 0
Unknown PPTP Pkts: 0

PPTP-GRE Session Stats:

Total Uplink Bytes: 0 Total Downlink Bytes: 0
Total Uplink Pkts: 0 Total Downlink Pkts: 0

• show user-plane-service statistics analyzer name h323: Use this command to view H323-related
statistics.
H323 Session Stats:
Total Uplink Bytes 0 Total Downlink Bytes 0
Total Uplink Packets 0 Total Downlink Packets 0
Total H323 calls 0
Total RAS messages 0
Total Q931 messages 0
Total H245 messages 0

• show user-plane-service statistics analyzer name h323 protocol ras: Use this command to view
the h323 protocol ras statistics.
Total RAS messages 0
RAS messages Uplink
Downlink
-------------- ------------
------------
GatekeeperRequest 0
0
GatekeeperConfirm 0
0
GatekeeperReject 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
375
 Cisco Confidential - Limited Release
NAT ALG Support
Monitoring and Troubleshooting

0
RegistrationRequest 0
0
RegistrationConfirm 0
0
RegistrationReject 0
0
UnregistrationRequest 0
0
UnregistrationConfirm 0
0
UnregistrationReject 0
0
AdmissionRequest 0
0
AdmissionConfirm 0
0
AdmissionReject 0
0
LocationRequest 0
0
LocationConfirm 0
0
LocationReject 0
0
DisengageRequest 0
0
DisengageConfirm 0
0
DisengageReject 0
0
InfoRequest 0
0
InfoRequestResponse 0
0
RequestInProgress 0
0
Unclassified 0
0

• show user-plane-service statistics analyzer name h323: Use this command to view H323-related
statistics.
H323 Session Stats:
Total Uplink Bytes 0 Total Downlink Bytes 0
Total Uplink Packets 0 Total Downlink Packets 0
Total H323 calls 0
Total RAS messages 0
Total Q931 messages 0
Total H245 messages 0

• show user-plane-service statistics analyzer name h323 protocol h245 : Use this command to
view the h323 protocol h245 statistics.
Total H245 messages 0
H245 messages Uplink Downlink

------------- ------------
------------
OpenLogicalChannel 0
0
OpenLogicalChannelAck 0
0
OpenLogicalChannelReject 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
376
 Cisco Confidential - Limited Release
NAT ALG Support
Monitoring and Troubleshooting

0
OpenLogicalChannelConfirm 0
0
RequestChannelClose 0
0
CloseLogicalChannel 0
0
CloseLogicalChannelAck 0
0
EndSessionCommand 0
0
Unclassified 0
0

• show user-plane-service statistics analyzer name h323 protocol q931 : Use this command to
view the h323 protocol q931 statistics.
Total Q931 messages 0
Q931 messages Uplink Downlink

------------- ------------
-------------
Alerting 0
0
CallProceeding 0
0
Setup 0
0
Connect 0
0
ReleaseComplete 0
0
Facility 0
0
Progress 0
0
Information 0
0
Unclassified 0
0

• show user-plane-service statistics analyzer name tftp: Use this command to view TFTP-related
statistics.
TFTP Session Stats:
Total Uplink Bytes: 0 Total Downlink Bytes: 0
Total Uplink Packets: 0 Total Downlink Packets: 0
Total Read Sessions: 0 Total Write Sessions: 0
Total Invalid Control Packets: 0
Total Invalid Data Packets: 0
Total Packets with Unknown Request Type: 0

TFTP DATA Session Stats:

Total Uplink Bytes: 0 Total Downlink Bytes: 0
Total Uplink Packets: 0 Total Downlink Packets: 0

• show user-plane-service statistics analyzer name sip: Use this command to view SIP-related statistics.
SIP Session Stats:
Total Uplink Bytes: 0 Total Downlink Bytes: 0
Total Uplink Pkts: 0 Total Downlink Pkts: 0
Uplink Valid Pkts: 0 Downlink Valid Pkts: 0
Uplink Retry Pkts: 0 Downlink Retry Pkts: 0
Uplink Error Pkts: 0 Downlink Error Pkts: 0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
377
 Cisco Confidential - Limited Release
NAT ALG Support
Monitoring and Troubleshooting

Total SIP Calls: 0

SIP Advanced Session Stats:
Total Uplink Bytes 0 Total Downlink Bytes 0
Total Uplink Packets 0 Total Downlink Packets 0

Total SIP Calls 0 Current SIP Calls 0

Total SIP UDP Calls 0 Current SIP UDP Calls 0
Total SIP TCP Calls 0 Current SIP TCP Calls 0

SIP Request Total received Total transmitted

Retransmitted
----------- -------------------- --------------------
--------------------
Register 0 0
0
Invite 0 0
0
Ack 0 0
0
Bye 0 0
0
Info 0 0
0
Prack 0 0
0
Refer 0 0
0
Cancel 0 0
0
Update 0 0
0
Message 0 0
0
Options 0 0
0
Publish 0 0
0
Subscribe 0 0
0
Notify 0 0
0

SIP Response Total received Total transmitted

Retransmitted
------------ -------------------- --------------------
--------------------
1XX 0 0
0
2XX 0 0
0
3XX 0 0
0
4XX 0 0
0
5XX 0 0
0
6XX 0 0
0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
378
 Cisco Confidential - Limited Release

CHAPTER 47
N : M Redundancy
• Revision History, on page 379
• Feature Description, on page 379

Revision History
Revision Details Release
With this release, a CLI is introduced to reduce the fail-over time during a 21.19
switchover.
With this release, a CLI is introduced to perform planned switchover from Active 21.18.1
to Standby UP.
This feature is not fully qualified in this release.

With this release, the feature is enhanced to support BFD and BGP monitor CLI 21.17
commands for switchover scenarios.
This feature is not fully qualified in this release.

First introduced. 21.16.1

This feature is not fully qualified in this release.

Feature Description
The CUPS User Plane (UP) is an all-important network component in the core network that carries and anchors
the data traffic of subscribers. To ensure a smooth quality of experience (QoE), it is necessary to preserve
data traffic and continue with minimal interruption. This is feasible only when there is a provision of a robust
redundancy mechanism for all the data sessions that are hosted and anchored on UPs.
Every UP should have a redundant UP on standby (warm, hot, or active). However, this model mandates
significant resource requirement for the service providers and is not a preferred model because of the number
of UPs that can keep scaling horizontally. The preferred model is to have an N:M model with multiple UPs
acting as standby-UPs for every active UPs. The N:M Redundancy feature provides this redundancy model.
On the UP, there is a new Cisco proprietary node called the Redundancy and Configuration Manager (RCM)
which handles the configuration management of the UPs and the redundancy functionality.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
379
 Cisco Confidential - Limited Release
N : M Redundancy
Feature Description

For details on N:M redundancy and RCM, refer the Redundancy and Configuration Manager Configuration
and Administration Guide.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
380
 Cisco Confidential - Limited Release

CHAPTER 48
Netloc and RAN/NAS Cause Code
• Revision History, on page 381
• Feature Description, on page 381
• Configuring Netloc and RAN/NAS Cause Code, on page 381

Revision History
Revision Details Release

First introduced. 21.13

Feature Description
The Netloc and RAN/NAS Cause Code feature is supported in non-CUPS architecture. With this release, this
feature is qualified in CUPS architecture.
This feature is used to send detailed RAN and/or NAS release cause code information from the access network
to PCRF.
This feature is in compliance with Release 12 specification of 3GPP TS 29.212.
If the supported features "netloc-ran-nas-code" and "netloc" are enabled, then netloc-ran-nas-cause code are
sent to the PCRF through CCR-U/CCR-T message.
In the Charging-Rule-Report AVP and CCR-T, the Diameter AVP “RAN-NAS-Release-Cause” is included
for bearer and session deletion events respectively when the NetLoc-RAN-NAS-Cause supported feature is
enabled and the RAN/NAS cause is received from the access side.
In the CCR-U and CCR-T, the network location is sent in the Diameter AVP “3GPP-User-Location-Info”
and/or “3GPP-MS-TimeZone” is included for creation/updation/deletion of bearer or session events respectively
when the NetLoc-RAN-NAS-Cause supported feature is enabled and the Netloc is received from the access
side.

Configuring Netloc and RAN/NAS Cause Code

Use the following configuration to enable the feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
381
 Cisco Confidential - Limited Release
Netloc and RAN/NAS Cause Code
Configuring Netloc and RAN/NAS Cause Code

configure
contextcontext_name
ims-auth-serviceservice_name
policy-control
diameterencode-supported-featuresnetloc-ran-nas-cause
end
NOTES:
• netloc-ran-nas-cause: Enables the Netloc-RAN-NAS-Cause feature. By default, this supported feature
will be disabled.
• If the supported features "netloc-ran-nas-code" and "netloc" are enabled, then netloc-ran-nas-cause code
will be sent to PCRF.
• To disable this supported feature, use the following command:
[ default | no ] diameter encode-supported-features
• This feature is supported only for standard Gx dictionary (r8-gx-standard and dpca-custom8).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
382
 Cisco Confidential - Limited Release

CHAPTER 49
New Standard QCI Support
• Revision History, on page 383
• Feature Description, on page 383

Revision History
Revision Details Release

First introduced. 21.14.a0 (EFT)

Feature Description

Important The New Standard QCI Support is an existing feature that is supported in non-CUPS architecture. With this
release, the feature is qualified in CUPS architecture.

The CUPS architecture supports new standard QCIs (65,66,69, and 70), based on 3GPP TS 23.203 Release
12, for Mission Critical and Push-to-Talk (MC/PTT) applications.
As part of this feature, the following functionality are supported:
• Creation, deletion, and updation of default and dedicated bearers.
• All applicable charging records includes the new standard QCI values.
• All other features, related to QCIs, work with the new standard QCI values.

Limitations
In current release, the following are the known limitations of this feature:
• S2a/S2b/GGSN are not supported.
• The overall eMPS functionality is not supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
383
 Cisco Confidential - Limited Release
New Standard QCI Support
Limitations

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
384
 Cisco Confidential - Limited Release

CHAPTER 50
Network Provided Location Indication
• Revision History, on page 385
• Feature Description, on page 385
• How It Works, on page 385

Revision History
Revision Details Release

With this release, NPLI for WiFi and LTE-WiFi handover scenarios are 21.16.x (FCS7)
supported.

First introduced. 21.14.0 (6/27/2019)

Feature Description
This feature enables the P-GW to provide the required access network information to the PCRF within the
TWAN-Identifier AVP, User-Location-Info-Time AVP (if available), and/or UE-Local-IP-Address AVP as
applicable for S2a/S2b. The P-GW also provides the ACCESS_NETWORK_INFO_REPORT event trigger
within Event-Trigger AVP.

Important The Network Provided Location Indication (NPLI) is an existing feature that is supported in non-CUPS
architecture. With this release, the feature is qualified in CUPS architecture. For more information, refer the
NetLoc for WiFi EPC chapter in the SAEGW Administration Guide.

How It Works
During bearer deactivation or UE detach procedure, the P-GW provides the access network information to
the PCRF within the TWAN-Identifier AVP and information on when the UE was last known to be in that
location within User-Location-Info-Time AVP, and/or UE-Local-IP-Address AVP as applicable for S2a/S2b.
If the PCRF request for user-location information as part of the Required-Access-Info AVP and it is not

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
385
 Cisco Confidential - Limited Release
Network Provided Location Indication
Supported Functionality

available in the P-GW, then the P-GW provides the serving PLMN identifier within the
3GPP-SGSN-MCC-MNC AVP.
Previously, the P-GW notified ULI/MS-TimeZone/PLMN-ID to ECS/IMSA/PCRF only when their value
changed. With this feature, the P-GW receives NetLoc indication in the rules sent by ECS regardless of whether
the values changed, and it sends this to the ECS/IMSA/PCRF. If the P-GW receives NetLoc as "1", then it
informs the MS-Timezone. If the P-GW receives NetLoc as '0', then it informs the ULI and ULI Timestamp.
If ULI is not available in that case, then the PLMN-ID is sent. If NetLoc indication is received for an update,
then the P-GW indicates this information to the access side in the UBReq using the RetLoc Indication flag.
This is required for VoLTE and aids in charging and LI functionality in IMS domain. This feature allows EPC
to support an efficient way of reporting ULI and Time-Zone information of the subscriber to the IMS core
network.
NOTE: In CUPS, when dedicated bearer is created by PCRF, it waits for CBRsp to trigger the CCR-I (for
new bearer, NSAPI) towards OCS server. Since there is no usage for this bearer until this point, instead of
sending a CCR-I with old access side information and following it up with a new CCR-U with updated access
side information, the P-GW sends a single CCR-I message with updated access side information.

Supported Functionality
Netloc sent in CBRes/DSReq/UBRes/DBC/DBRes is supported on Gx, Gy, and Gz interfaces. The NPLI
feature is supported for:
• Pure-P, Collapsed, and Pure-S sessions
• WiFi sessions
• S-GW Relocation
• Session Recovery

Limitations
The NPLI feature has the following limitations:
• GnGp handover scenarios are not supported.
• When there is a change in Netloc in UBRes, CDR for TimeZone change is not generated.
• When there is a ULI change in Netloc in DSReq, serviceConditionChange is blank in the CDR.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
386
 Cisco Confidential - Limited Release

CHAPTER 51
Nexthop Forwarding Support IPv4/v6 Address
• Revision History, on page 387
• Feature Description, on page 387
• How It Works, on page 387
• Configuring Nexthop Forwarding Support IPv4/IPv6 Address, on page 391
• Monitoring and Troubleshooting, on page 392

Revision History
Table 27: Revision History

Revision Details Release

First introduced 21.19

Feature Description
In uplink direction at CUPS UPF, UE IP and the GI IP might be in a different subnet and the routing path is
defined to allow the uplink packet forward accordingly.

How It Works
Architecture
The following illustration provides EGCI-based P-GW UP Selection Solution overview.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
387
 Cisco Confidential - Limited Release
Nexthop Forwarding Support IPv4/v6 Address
Architecture

Figure 21: Nexthop Forwarding

Configuration Priority

Configuration Priority

1. AAA (Only IPv4) 1

2. APN(Gn/VAPN) 2

3. IP Pool 3

Configuration Use Cases

Case IP Type AAA APN IP Pool Nexthop IP Selection

Nexthop supplied IPv4 10.10.10.10 Not configured Not configured Nexthop Address
Only in AA message Selected from AAA:
over AAA IPv6 Not Not configured Not configured IPv4: 10.10.10.10
supported IPv6: NA

Nexthop that is IPv4 10.10.10.10 15.15.15.15 50.50.50.50 Nexthop Address is

supplied in AA selected from AAA:
message over AAA + IPv46 Not Not configured Not configured IPv4: 10.10.10.10
IPv4 Configured in supported IPv6: NA
APN & IP Pool

IPv4 & IPv6 IPv4 Not 15.15.15.15 Not configured Nexthop Address is
Configured in APN configured selected from APN:
only IPv4: 10.10.10.10
IPv6 Not 9001::3 Not configured IPv6: 9001::3
supported

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
388
 Cisco Confidential - Limited Release
Nexthop Forwarding Support IPv4/v6 Address
Architecture

Case IP Type AAA APN IP Pool Nexthop IP Selection

IPv4 & IPv6 IPv4 Not Not configured 50.50.50.50. Nexthop Address is
Configured in IP configured selected from IP Pool:
Pool only IPv4: 10.10.10.10
IPv6 Not Not configured 5002::5 IPv6 : 5002::5
configured

IPv4 Available over IPv4 10.10.10.10 15.15.15.15 50.50.50.50 Nexthop IPv4 is

AAA + IPv4 & IPv6 selected from AAA:
configure on APN & IPv6 Not 9001::3 5002::5 10.10.10.10 Nexthop
IP Pool Supported IPv6 selected from
APN : 9001::3

IPv4 Available over IPv4 10.10.10.10 Not configured 50.50.50.50 Nexthop IPv4 is
AAA + IPv4 & IPv6 selected from AAA:
configure on IP Pool IPv6 Not Not configured 5002::5 10.10.10.10 Nexthop
Supported IPv6 selected from IP
Pool: 5002::5

IPv4 Available over IPv4 10.10.10.10 15.15.15.15 Not configured Nexthop IPv4 is
AAA + IPv4 & IPv6 selected from AAA:
configure on APN. IPv6 Not 9001::3 Not configured 10.10.10.10 Nexthop
Supported IPv6 selected from
APN: 9001::3

Interface
Following Private IEs are introduced in SX Session Establishment message.

2 PFCP Sx Private
_IE_ Session IE :
3
NEXT Establish CUPS:
PFCP_IE_NEXTHOP
8 nexthop
HOP ment
forward
Request
ing
BITS support-
IPv4
Octets 7 6 5 4 3 2 1
/IPv6
1 to 2 Type = 238 (decimal) address

3 to 4 Length = n

5 to
PFCP_IE_NEXTHOP_ID
10

11-14 PFCP_IE_NEXTHOP_IP

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
389
 Cisco Confidential - Limited Release
Nexthop Forwarding Support IPv4/v6 Address
Architecture

2 PFCP 1. Inside Private

_IE_ create far IE :
3
NEXTHOP IE of Sx CUPS:
PFCP_IE_NEXTHOP_ID
9 _ID Session nexthop
Establishment forwarding
Request support-
IPv4
BITS 2. Inside /IPv6
PFCP address
_IE_
NEXTHOP
IE of Sx
Session
Establishment
Request

Octets 7 6 5 4 3 2 1 PFCP
_IE_
1 to NEXTHOP
Type = 239 (decimal)
2 of Sx
Session
3 to Establishment
Length = 5
4 Request
5 to
10

2 PFCP_IE_
NEXTHOP PFCP_IE_NEXTHOP_IP
4
_IP
0
Bits PFCP_IE_ Private
NEXTHOP IE :
Octets 7 6 5 4 3 2 1 of Sx CUPS:
Session nexthop
1 to 2 Type = 240 (decimal) Establishment forwarding
3 to 4 Length = n Request support-
IPv4/
5 spare V4 V6 IPv6
address
m to
IPv4 Address
m+3

p to
IPv6 Address
p+15

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
390
 Cisco Confidential - Limited Release
Nexthop Forwarding Support IPv4/v6 Address
Configuring Nexthop Forwarding Support IPv4/IPv6 Address

Configuring Nexthop Forwarding Support IPv4/IPv6 Address

Configuring Nexthop Forwarding at APN Configuration Mode
Use the following CLI commands to configure Nexthop Forwarding at APN.
configure
contex contex_name
apn apn_name
nexthop-forwarding-address ipv4/v6_address/ipv4_&_ipv6 address
no nexthop-forwarding-address
end
NOTES:
• no: Disables Nexthop forwarding address configuration.
• nexthop-forwarding-address ipv4/v6_address/ipv4_&_ipv6 address: Configures the Nexthop forwarding
address for this APN.
• ipv4_address Configures IPv4 address.
• ipv6_address Configures IPv6 address (supports colon-separated hexadecimal notation).

Configuring Nexthop Forwarding at IP Pool

Use the following CLI commands to configure Nexthop Forwarding at APN.
configure
contex contex_name
[ no ]ip pool ipv4/v6_address nexthop-forwarding-address ipv4/v6_address
end
NOTES:
• no: Disables Nexthop forwarding address configuration.
• nexthop-forwarding-address ipv4/v6_address: Configures the Nexthop forwarding address for this
pool.
• ipv4_address Configures IPv4 address.
• ipv6_address Configures IPv6 address (supports colon-separated hexadecimal notation).

Configuring Nexthop Forwarding Through AAA

Nexthop Forwarding Address can be configured through AAA also, this option allows us to configure externally.
Configuring Nexthop Forwarding externally:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
391
 Cisco Confidential - Limited Release
Nexthop Forwarding Support IPv4/v6 Address
Monitoring and Troubleshooting

RADIUS AUTHENTICATION
Access-Accept
Subscriber-Nexthop-Address

Monitoring and Troubleshooting

This section provides information about CLI commands available for monitoring and troubleshooting the
feature.

Show Commands and Outputs

This section provides information about show commands and their outputs in support of this feature.

show apn name <apn_name>

The output of this show command is enhanced to include the following fields introduced in support of this
feature.
• nexthop gateway addr: Displays the configured Nexthop gateway address.

show subscriber user-plane-only full all

The output of this show command is enhanced to include the following fields introduced in support of this
feature.
• Next Hop Ip Address - Displays the configured Nexthop IP address.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
392
 Cisco Confidential - Limited Release

CHAPTER 52
Network Trigerred Service Restoration
• Feature Description, on page 393
• Configuring NTSR, on page 393
• Monitoring and Troubleshooting, on page 395

Feature Description
The Network Triggered Service Restoration (NTSR) feature detects an MME failure when enabled on the
S-GW. If the subscriber served by the failed MME receives any downlink data packets, then the S-GW selects
an alternate MME from the NTSR pool in round-robin fashion. The S-GW then sends a Downlink Data
Notification (DDN) to the selected MME. This round robin selection of an MME is per session manager
instance and not system wide.
The NTSR feature improves load balancing of DDN messages in the network during an MME failure.
In CUPS mode, bearers which are applicable for restoration, the corresponding downlink data is buffered on
User Plane. For bearers that are not configured for restoration, the corresponding traffic endpoints are removed
from the User Plane.
If S-GW detects that dedicated bearers are retained from a particular PDN, the S-GW retains the default bearer
as well for this PDN. In this case, Downlink data will be dropped on default bearer.
On receiving any downlink data/Update Bearer Request/Create Bearer Request in restoration pending state,
the SGW initiates a DDN request event towards MME or S4-SGSN.
Upon receiving Modify Bearer Request from MME, Control Plane sends Sx Session Modification Request
to User Plane with UPDATE FAR:APPLY ACTION:FORW=1 for all bearers which are applicable for
restoration.

Configuring NTSR
The NTSR feature involves the following configurations:
• APN Profile Configuration
• Peer Profile Configuration (Ingress)
• NTSR Pool Configuration
• S-GW Service Access Peer Map Association

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
393
 Cisco Confidential - Limited Release
Network Trigerred Service Restoration
APN Profile Configuration

• MME Restoration Timer Configuration

APN Profile Configuration

In this configuration, the QCI and ARP values are configured in the APN profile. When path failure is detected
on the ingress side of the S-GW, bearers are retained or released based on the configured ARP/QCI values.
S-GW can configure a maximum of two QCI and ARP-watermark combination per APN-profile.
Use the following commands to configure the ARP and QCI values in the APN profile.
configure
apn-profile profile_name
ntsr { all | qci qci_value | arp-priority-watermark arp_value }
end
NOTES:
• ntsr: Specifies the NTSR configuration.
• qci: Specifies the QCI value for NTSR.
• arp-priority-watermark: Specifies the ARP value for NTSR.
• all: Identifies for all bearers with QCI or ARP values for MME restoration.

Peer Profile Configuration (Ingress)

In this configuration, the Peer Profile is configured on the ingress side of S-GW. The peer profile contains an
associated pool-id, which is used to detect MME/S4-SGSN pool after MME failure.
Use the following commands to configure peer-profile on the ingress side at S-GW.
configure
peer-profile service-type sgw-access name name
ntsr pool-id pool_id
end
NOTES:
• sgw-access: Configures the profile for peer nodes of S-GW towards S4/S11 interfaces.
• ntsr: Specifies the NTSR configuration.
• pool-id: Specifies the pool ID to detect MME/S4-SGSN pool after MME failure. The pool_id is an integer
in the range of 1 to 10.

NTSR Pool Configuration

The NTSR pool configuration is used to configure pool of IP addresses associated with a pool-id and a peer
type. One pool ID can be used for one peer-type. The NTSR pool can have combination of IPv4 or IPv6
address. S-GW can be configured with a maximum of 10 NTSR pools, and with at maximum of 5 IPv4v6 IP
address pairs.
Use the following configuration to configure the NTSR Pool.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
394
 Cisco Confidential - Limited Release
Network Trigerred Service Restoration
S-GW Service Access Peer Map Association

configure
ntsr-pool pool-id pool_id peer-type [ mme | s4-sgsn ]
[ no ] peer-ip-address { ipv4-address ipv4_address | ipv6-address
ipv6_address }
end
NOTES:
• pool-id: Specifies the NTSR pool ID.
• peer-type: Specifies the NTSR Pool ID peer type. The peer type is either MME or S4-SGSN.
• peer-ip-address: Configures the IPv4 address or IPv6 address as a part of the MME or S4-SGSN pool.

S-GW Service Access Peer Map Association

In this configuration, the peer map on the Access side or Ingress side of S-GW service is configured.
Use the following configuration to associate a peer map to an S-GW service.
configure
context context_name
sgw-service service_name
associate access-peer-map peermap_name
end
NOTES:
• access-peer-map: Configures the Access/Ingress side peer map for an S-GW service.

Monitoring and Troubleshooting

Show Commands Input and/or Outputs
This section provides information regarding show commands and their outputs in support of the feature.

show apn-profile full all

The output of this command displays the following fields in support of this feature:
• NTSR
• QCI
• ARP-priority-watermark

show apn-profile full name apn_name

The output of this command displays the following fields in support of this feature:
• NTSR
• QCI

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
395
 Cisco Confidential - Limited Release
Network Trigerred Service Restoration
show ntsr-pool all

• ARP-priority-watermark

show ntsr-pool all

The output of this command displays the following fields in support of this feature:
• SGW NTSR pools
• NTSR pool-id
• NTSR Pool type
• NTSR pool-id
• NTSR Pool type

show ntsr-pool full all

The output of this command displays the following fields in support of this feature:
• NTSR pool-id
• NTSR Pool type
• peer-address-pair(s)

show ntsr-pool full pool-id pool_id

The output of this command displays the following fields in support of this feature:
• NTSR pool-id
• NTSR Pool type
• peer-address-pair(s)

show ntsr-pool pool-id pool_id

The output of this command displays the following fields in support of this feature:
• NTSR pool-id
• NTSR Pool type

show sgw-service statistics all

The output of this command displays the following fields in support of this feature:
• Peer Failure
• Retained
• Restored
• Released

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
396
 Cisco Confidential - Limited Release
Network Trigerred Service Restoration
show subscribers sgw-only full all

• Peer Restart
• Retained
• Restored
• Released

show subscribers sgw-only full all

The output of this command displays the following fields in support of this feature:
• NTSR state
• Bearer capable restoration

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
397
 Cisco Confidential - Limited Release
Network Trigerred Service Restoration
show subscribers sgw-only full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
398
 Cisco Confidential - Limited Release

CHAPTER 53
NSH Traffic Steering
• Revision History, on page 399
• Feature Description, on page 399
• How it Works, on page 402
• Configuring the L2 and NSH Traffic Steering Feature, on page 407
• N to M Traffic Steering, on page 411
• Interworking with Inline Features, on page 416
• Monitoring and Troubleshooting, on page 416

Revision History
Revision Details Release

NSH support, monitoring and troubleshooting, SFP selection, OAM 21.20.3

statistics, N:M configuration, interworking with inline features, and
limitations are updated in this release.
This feature is fully qualified in this release.

First introduced. 21.19.1

This feature is not fully qualified in this release.

Feature Description
The 3GPP EPC architecture enables data traffic steering across various service functions on the Gi interface.
The traffic steering architecture is based on the Network Service Header (NSH) service chaining protocol.
The EPC gateway needs to perform the traffic steering to steer the traffic across the multiple service chains
containing the appliances which support NSH.

Architecture
The following figure illustrates the architectural setup for CUPS based gateway for NSH appliances.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
399
 Cisco Confidential - Limited Release
NSH Traffic Steering
Components

Figure 22: NSH Traffic Steering Architecture

The feature supports a service function chain for NSH supported appliances. The gateway is configured to
select a suitable steering or encapsulation method for steering traffic that is based on each appliance instance
or group.

Components
The traffic steering architecture comprises of the following main components:

Control Plane (SAEGW-C)

CP sends information to UP on how to steer the subscriber’s traffic. The UP steers all or only part of the
subscriber data traffic that is based on policies that are defined for the subscriber. It's possible to steer different
types of subscriber traffic to different service function chains.
CP selects the service chain name for a subscriber after it receives the Ts-subscription-scheme AVP from
PCRF, which is based on locally configured policies.

User Plane (SAEGW-U)

Based on the policy, which UP receives from CP, it steers the subscriber data traffic to one or more service
function chains.
UP also performs the following functions:
• Select a Service Function Path (SFP) for a particular Service Function Chain (SFC).
• Maintain subscriber stickiness while forwarding traffic toward the appliances.
• If a node or an appliance fails, reselect and steer the subscriber data traffic to a new node.
• Manage In-Service and Out-of-Service status for SFPs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
400
 Cisco Confidential - Limited Release
NSH Traffic Steering
Limitations

• Manage SFC status depending on the number of serviceable SFPs available within an SFC.

NSH
For monitoring health of the NSH appliance, each SAEGW-U/UPF is responsible for monitoring of the
appliance load and serviceability stat.
• Use the OAM NSH packet mechanism to monitor the status of the appliances.
• The monitoring frequency for the configuration is (1-20 secs) with a default interval of 1 sec.
• In case the OAM request times out. Do the retry. The timeout and the retry value are configurable with
values of 1-5 secs for timeout (default of 3 secs) and 1-3 retries (default of two retries).
• In addition to the appliance serviceability status, the current load on the appliance is under observation.
Monitor the current load in order to maintain the optimum load balancing among various instances of
an SF. This load status returns through the NSHs OAM response packet.

Limitations
The NSH traffic steering has the following limitations:
• On NSH appliance, make sure that the interface fragmentation doesn’t happen. Keep the MTU towards
the NSH appliance interface bigger than Gn/Gi interface.
• For HTTP pipelined sessions, mid flow HTTP partial packets, and TCP Out of order packets, if requires
an SFP revaluation with L7 conditions, doesn’t reach the NSH appliance.
• If you remove the SFP ID configuration from the main configuration, show configuration still shows the
SFP ID. The SFP ID goes away once committed to VPP, using the commit CLI.
• Traffic steering statistics indicate the packets which are candidate for traffic steering. In traffic steering
statistics those packets are also counted which are dropped by quota exhaust, though they still are the
candidates for traffic steering.
• If modification of NSH SRC/bind IP address OR appliance IP address is required in the configuration
for any NSH appliance’s instance, then you need to remove the instance, then SFPs associated with it,
put the SFPs and new instance with modified IP addresses. Perform the commit afterwards.
• When node failure is done and continuous data is coming, then there can be discrepancy in steering
statistics. Data steered on SFPs which is going down is not reflected in statistics.
• For multi PDN call, NSH instance stickiness is restricted to each subscriber session.
• In case of a change in the state at the SAEGW-U due to ICSR or config change like SFP removal in the
interim period, there is a possibility that packets which are being hair pinned back from the appliance in
this window can be dropped. All further incoming packets are processed as normal
• In case of the first packet of a flow being a DL packet (session recovery), just that first packet is dropped.
However, the retransmitted packet and all subsequent packets are sent out as normal.
• In case of change in the NSH format tags, tag types stream-fp-md encode, reverse-stream-fp-md ,
secondary-srv-path-hdr, and rating-group comes into effect for new flows and not for existing flows.
Any changes for the remaining tags in the NSH format applies for new sessions while traffic on existing
sessions continue with older format tags. In such cases, particularly in case of modification and deletion

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
401
 Cisco Confidential - Limited Release
NSH Traffic Steering
How it Works

of tags, the appliance can mismatch the tag values received in the NSH packets and can lead to ambiguous
behavior. So, perform the NSH-format type changes carefully.
• Server initiated TCP Flows are not considered for Traffic steering.
• Monsub support for capturing NSH traffic is not currently available.
• For addressing any appliance level limitation (example - traffic type), policy selection configuration on
the service scheme provides the flexibility to filter out such traffic from selecting a service chain containing
such appliance.
• For N:M setup, service scheme config (trigger action, trigger condition, service-scheme, subscriber class,
and subscriber base) needs to be configured in Day-0 config on UP. Service scheme when configured,
in common config on UP, is hitting a race condition leading to service scheme not getting configured on
user-plane sessmgrs intermittently, which leads to failure of traffic steering functionality.
• OAM stats for L2 steering is partially supported.
• For HTTP concatenated packet, the packet is traffic steered based on the policy matched by the last HTTP
GET in the packet.
• In case a appliance goes down, the flow gets onloaded for revaluation when the next uplink packet is
recovered on the flow. Post which the a new SFP selection happens and the traffic is steered to the new
appliance.

How it Works
Packet Flows
This section describes the packet flows for the NSH traffic steering architecture.

Uplink Packets
Figure 23: Uplink Packet Flow

1. UE sends the subscriber data packets to SAEGW-U.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
402
 Cisco Confidential - Limited Release
NSH Traffic Steering
Packet Flows

2. SAEGW-U classifies the subscriber data traffic that is based on subscriber policies, and identifies an SFC
to select an SFP accordingly.
3. SAEGW-U steers the Uplink (UL) packets with NSH encapsulation as per NSH RFC and sends to NSH
appliance.
SAEGW-U sends the non-steered IP packets to the server.
4. NSH supported appliance on receiving uplink packet, takes the decision to forward the packet to server
based on certain criteria.

Downlink Packets
Figure 24: Downlink Packet Flow

1. SAEGW-U receives the Downlink (DL) packets from the server.

2. SAEGW-U selects an SFP.
3. SAEGW-U adds metadata as NSH context header and forwards it to the NSH supported appliance.
4. The NSH supported appliance sends back the packets to the SAEGW-U with the some metadata tags,as
sent by SAEGW-U.
5. On receiving the packets, SAEGW-U classifies the subscriber data traffic that is based on subscriber
charging policies.
6. SAEGW-U sends the data packets to the subscriber.

Deployment Model
The following figure illustrates the deployment model for the NSH steering.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
403
 Cisco Confidential - Limited Release
NSH Traffic Steering
Packet Flows

Figure 25: Deployment Model

Table 28: Deployment Model Call Flow

Step Description

1. UL packet received at the SAEGW-U is classified

based on the configured policy associated with the
appropriate SFC.

2. The Saegw performs the SFP selection based on the

stickiness (MSISDN stickiness) or service and load
availability of the SFPs. The UL traffic is NSH
(IP-UDP) encapsulated steered on the selected SFP
with the context header populated as necessary.

3. The NSH appliance on receiving the NSH Packet,

processes the IP packet (and possibly the context
header) and sends the packet over the Gi interface.

4. Destination server sends the DL packet from the Gi

interface to the SAEGW-U. The DL traffic is NSH
(IP-UDP) encapsulated steered on the selected SFP
with the context header populated as necessary.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
404
 Cisco Confidential - Limited Release
NSH Traffic Steering
NSH Traffic Steering Requirements

Step Description

5. The NSH appliance on receiving the NSH Packet,

processes the IP packet (and possibly the context
header) and hairpin the packet back to the SAEGW-U.

6. The SAEGW-U on receiving the NSH packet:

• Decapsulates the received payload
• Processes the IP packet (and possibly the context
header) and send the packet over the Gn interface
to the UE

NSH Traffic Steering Requirements

Following is the behavior for integration of NSH appliances in the Traffic steering solution:
• SAEGW-U maintains the session stickiness of NSH appliance and ensure that all flows of a subscriber
session end up selecting the same appliance instance.
• There’s a configurable option to define the load capacity for every appliance instance, example 50%,
100%. If the load status by the NSH appliance exceeds this threshold, only existing subscribers can
continue with such instance. This instance doesn’t allocate to any new subscriber until the load status
falls below the threshold.
• If NSH appliance detects as DEAD, all traffic on SFPs engaging this appliance instance is reclassified
and traffic moves to a different appliance instance. Such appliance isn’t available for new subscriber
selection once it comes back ALIVE.
• Traffic Steering can be enable/disable in midsession. If you enable the traffic steering in between, then
it’s applicable to new flows. Old flows continue without traffic-steering.
• SR/ICSR support for traffic-steering Post SR/ICSR session stickiness is maintained.
• In case of multi appliance SFP, there are two forms of configurations:
• For cases where appliances need to see start of traffic (example - TWH Packets), an SFP is selected
which engages all appliances. As per the configuration policies, when the classification happens,
the traffic can fall out of ineligible appliances.
• For cases where appliances engage in mid flow, the configuration is such that appliances engage
once the certain appliances become eligible further to traffic classification.

• Traffic steering statistics indicate the packets which are candidate for traffic steering. For traffic steering
statistics, those packets are also counted which are dropped by quota exhaust, though they are the
candidates for traffic steering.
• When node failure is done and continuous data is coming, then there can be discrepancy in steering
statistics. Data steered on SFPs which is going down is not reflected in statistics.
• If you want to modify the NSH remote IP add or SRC bind IP in the configuration for any NSH appliance
instance:
• Then remove the instance.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
405
 Cisco Confidential - Limited Release
NSH Traffic Steering
SFP Selection

• Then remove the SFPs associated with it.

• Put the SFPs and new instance with modified IP addresses.
• Perform the commit afterwards.

This feature supports the following Traffic steering system limits:

Traffic steering object Max

Limit
Total Appliance groups 16
Totsl Instances per Appliance Group 256
Total SFCs 16
Total SFPs 64000

Default Service Chain

For operator, there could be certain use cases, where all traffic for a subscriber who has traffic steering enabled,
needs to traverse through certain appliance(s). In order to cater to such requirement while providing an easy
configuration mechanism to achieve that, the concept of a default service chain has been brought in. For e.g.
if the subscriber is engaged on a subscriber with 2 appliances, APP1 and APP2 , where APP2 needs to see all
the traffic, a service chain containing APP2 would be configured as the default service chain.
Thus, for a traffic steering enabled subscriber, there could be unavailability of service chain APP1+APP2 for
certain traffic due the following conditions:
• There is no suitable policy configured for certain flows which would select the APP1+APP2 service
chain.
• APP1+APP2 service chain was selected ,but APP1 instances went down below the min instance threshold.
In such case the APP1+APP2 service chain will not be available.
• APP1+APP2 service chain was selected but no SFP could be selected.

Under such cases due to service chain unavailability, the flows would fall back to the configured default
service chain thus ensuring APP2 service treatment to the flows.
If a default service chain, however, if not configured, will lead to the traffic being sent out non-steered.

SFP Selection
SFP selectios is based on the:
• MSISDN Stickiness (preconfigured) or
• Load Availability

MSISDN Stickiness
MSISDN Stickiness depends on the MS-ISDN and it provides the corresponding node. If the node is available
and is part of the SFP, then that SFP is selected for the data (UL/DL). Presently, MSISDN stickiness is available
for the L2 nodes only and there can be a service chain having L2 nodes alone or with a mix of L2 and NSH.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
406
 Cisco Confidential - Limited Release
NSH Traffic Steering
Configuring the L2 and NSH Traffic Steering Feature

All SFPs of the service chain have same set of type of nodes, where type can be of L2 or L2 + NSH or NSH
(only).
Subscriber Stickiness (for both L2 and NSH) is maintained for the subscriber across the service chains till
that node is available and when node goes down or removed from the config, subscriber can move to a different
SFP (based on SFP selection). In case of stickiness miss, logs and traps are generated.

Load Availability
Load availability is load capacity, current load is maintained for each SFP (minimum of all instances that are
part of the SFP). The SFPs are classified as part of available, overloaded or blocked list based on load
availability. Only available-list and overloaded-list are being used for SFP selection as blocked-list is for SFPs
for which node is down. Available-list SFPs are available for both old and new calls/sessions. Overloaded-list
(load availability =0) is only used for maintaining the stickiness (if any), that is for old calls/sessions only.
SFPs, once selected may move to overloaded-list because of load and for maintaining the stickiness. Same
SFPs are used for the old calls/sessions and new calls use the remaining SFPs of the available-list for SFP
selection.

Configuring the L2 and NSH Traffic Steering Feature

The following sections provide information about the CLI commands available to configure the L2 and NSH
traffic steering CUPS feature in both CP and UP.

Configuring the Control Plane

The following CLI command is a sample configuration to configure CP under the active-charging service.
configure
active-charging service ACS
policy-control services-framework
trigger-action ta1
up-service-chain sc_owm

exit
trigger-action ta2
up-service-chain owm
exit

trigger-condition tc1
rule-name = rule1
rule-name = rule2
multi-line-or
exit

trigger-condition tc2
any-match = TRUE
exit

service-scheme scheme1
trigger rule-match-change
priority 1 trigger-condition tc1 trigger-action ta1
exit
trigger subs-scheme-received
priority 1 trigger-condition tc2 trigger-action ta2
exit

subs-class class1
subs-scheme = s1

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
407
 Cisco Confidential - Limited Release
NSH Traffic Steering
Configuring the L2 and NSH Traffic Steering Feature

exit
subscriber-base base1
priority 1 subs-class class1 bind service-scheme scheme1
exit
end

NOTES:
• subs-scheme - The name should match the subscription-scheme AVP value that is received from PCRF
over the Gx interface.
• up-service-chain SecNet - The value must match the up-service-chain that is configured on UP.
• rule-name - The value can be static/predef/gor/dynamic rules.

Traffic steering AVPs are currently supported with the Diameter dictionary custom44. The Diameter dictionary
enables CP to properly decode the TS-related AVPs when they are received over the Gx interface and sent in
Sx message to UP.
The following CLI command is a sample configuration to configure the dictionary in CP.
ims-auth-service IMSGx
policy-control
diameter dictionary dpca-custom44

Following are the sample values for TS Related AVPs received over GX in CCA-I/CCA-U/RAR.
[V] Service-Feature:
[V] Service-Feature-Type: TS (4)
[V] Service-Feature-Status: ENABLE (1)
[V] Service-Feature-Rule-Install:
[V] Service-Feature-Rule-Definition:
[V] Service-Feature-Rule-Status: ENABLE (1)
[V] Subscription-Scheme: scheme
[V] Profile-Name: Gold

Configuring the User Plane

The following CLI command is a sample configuration to add an interface in the contexts, which are used to
send data toward L2 and NSH supported appliance.
configure
require tsmon
end
configure
context ISP1-UP
interface <ts_ingress>
ip address <ip_address>
ipv6 address <ipv6_address_secondary>
exit
end

configure
context ISP2-UP
interface <ts_egress>
ip address <ip_address>
ipv6 address <ipv6_address_secondary>
exit
end

The following CLI command is a sample configuration to bind the newly added interfaces to the physical
ports in the UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
408
 Cisco Confidential - Limited Release
NSH Traffic Steering
Configuring the L2 and NSH Traffic Steering Feature

configure
port ethernet 1/11
vlan 1240
no shutdown
bind interface ts_ingress ISP1-UP
exit
exit
port ethernet 1/12
vlan 1240
no shutdown
bind interface ts_egress ISP2-UP
exit
exit
end

The following CLI command is a sample configuration to add the TS-related configuration in the UP.
config

ts-bind-ip IP_UP01 ipv4-address 40.40.40.106 ipv6-address 4001::106

nsh
node-monitor ipv4-address 40.40.40.107 ipv6-address 4001::107 poll-interval 1 retry-count
2 load-report-threshold 5 (node-monitor is mandatory for NSH appliances, default values
are poll-interval=1, retry-count=2, load-report-threshold=5)
up-nsh-format format1
tag-value 250 imsi encode
tag-value 66 msisdn encode
tag-value 4 rating-group encode
tag-value 1 stream-fp-md encode decode
tag-value 2 reverse-stream-fp-md encode decode
tag-value 76 subscriber-profile encode
tag-value 3 secondary-srv-path-hdr encode
tag-value 5 rat-type encode
tag-value 51 mcc-mnc encode
tag-value 255 apn encode
tag-value 25 sgsn-address encode
#exit
#exit
traffic-steering
up-service-chain sc_owm
sfp-id 9 direction uplink up-appliance-group secure-net instance 1 up-appliance-group
owm instance 1
sfp-id 10 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 1
sfp-id 11 direction uplink up-appliance-group secure-net instance 2 up-appliance-group
owm instance 1
sfp-id 12 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 2
sfp-id 13 direction uplink up-appliance-group secure-net instance 1 up-appliance-group
owm instance 2
sfp-id 14 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 1
sfp-id 15 direction uplink up-appliance-group secure-net instance 2 up-appliance-group
owm instance 2
sfp-id 16 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 2
sfp-id 17 direction uplink up-appliance-group secure-net instance 3 up-appliance-group
owm instance 1
sfp-id 18 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 3
sfp-id 19 direction uplink up-appliance-group secure-net instance 4 up-appliance-group
owm instance 1
sfp-id 20 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 4

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
409
 Cisco Confidential - Limited Release
NSH Traffic Steering
Configuring the L2 and NSH Traffic Steering Feature

sfp-id 21 direction uplink up-appliance-group secure-net instance 3 up-appliance-group

owm instance 2
sfp-id 22 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 3
sfp-id 23 direction uplink up-appliance-group secure-net instance 4 up-appliance-group
owm instance 2
sfp-id 24 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 4
#exit
up-service-chain owm
sfp-id 1 direction uplink up-appliance-group owm instance 1
sfp-id 2 direction downlink up-appliance-group owm instance 1
sfp-id 3 direction uplink up-appliance-group owm instance 2
sfp-id 4 direction downlink up-appliance-group owm instance 2
#exit
up-appliance-group owm
steering-type nsh-aware
up-nsh-format format4
min-active-instance 1
instance 1 ip address 40.40.40.3
instance 2 ip address 40.40.40.4
#exit
up-appliance-group secure-net
steering-type l2-mpls-aware
min-active-instance 1
instance 1 ingress slot/port 1/13 vlan-id 2136 egress slot/port 1/12 vlan-id 2136
ingress-context ingress ip address 4101::1 egress-context egress ip address 4101::2
instance 2 ingress slot/port 1/13 vlan-id 2137 egress slot/port 1/12 vlan-id 2137
ingress-context ingress ip address 4201::1 egress-context egress ip address 4201::2
instance 3 ingress slot/port 1/13 vlan-id 2138 egress slot/port 1/12 vlan-id 2138
ingress-context ingress ip address 4301::1 egress-context egress ip address 4301::2
instance 4 ingress slot/port 1/13 vlan-id 2139 egress slot/port 1/12 vlan-id 2139
ingress-context ingress ip address 4401::1 egress-context egress ip address 4401::2
#exit

To complete UP configuration for the feature, use the following CLI command:
configure
traffic-steering
commit
end

Configuration Guidelines
This section describes the following guidelines that are required to properly configure the feature:
• Configure the TS-related configuration on UP in the same sequence as mentioned in the preceding
sections. This method ensures that the interfaces used to steer traffic toward secure-net are applied
properly in the configuration.
• If the instance under up-appliance-group has to be modified or deleted, then all the associated sfp-id
under up-service-chain must be removed or deleted first.
• If the preceding modification must be done to the associated instance and sfp-id after a call is initiated,
then remove the sfp-ids and reconfigure them to avoid any issues.
• Apply any changes to the interface before configuring the up-appliance-group instance. If the changes
to the interface are applied at a later stage, remove the up-service-chain configuration first and then the
up-appliance-group configuration. After the interface modification is complete, reconfigure the service
chain and appliance group.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
410
 Cisco Confidential - Limited Release
NSH Traffic Steering
N to M Traffic Steering

• The entire UP service chain and appliance group must not be removed to remove an interface or sfpid.

N to M Traffic Steering
Following are the configuration steps for the N:M Traffic Steering:
1. Configure TS-bind ip in RCM host specific configuration for all active UPs.
2. Configure the required active charging ruledef, rulebase configurations and traffic steering configurations
(up-nsh format, up-appliance-group and up-service-chain, commit CLI) in common configuration in RCM
and do commit.
3. Reload the active and standby UP with Day-0 config which has require ts-mon, RCM config, node monitor
CLI for owm server monitoring, BFD related interfaces configuration for secureNet, and service schema
config for traffic steering (trigger condition, trigger action and so on).
4. Check RCM pushes config to all UPs. Check all services are up on all the UPs.
5. Check that the VPP fastpath tables have SST, SSMT, and SST tables created. Also check global tables
are created correctly.
6. Check the up-service-chain SFP status and make sure that the SFPs are in available state.

Configuration
Following are the sample configurations:
• Day-0 config : The following configurations are part of Day-0 config.
• Require ts-mon and Node-monitor CLI to monitor OWM appliance as mentioned in the earlier
configuration section. Each UP has its own physical IP to monitor OWM appliance.
• BFD related interfaces configuration for Securenet. Vlan configuration and IP interface related
configuration.
• Service schema configuration (Trigger condition, service scheme and so on).

Note Optimisation is planned to move service schema configuration to common

configuration. Currently if service scheme configuration needs to be modified
then changes needs be done manually on all the UPs.

UP Sample Configuration
OWM Monitoring
config
require ts-mon
nsh
node-monitor ipv4-address 40.40.40.254 poll-interval 5 retry-count 5
load-report-threshold 20
exit

interface ISP1_TO_PDN
ip address 40.40.40.254 255.255.255.0

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
411
 Cisco Confidential - Limited Release
NSH Traffic Steering
N to M Traffic Steering

ipv6 address 4001::254/64 secondary

#exit

Note on UP2, IP can be 40.40.40.454, this is physical IP address specific to that UP.

Securenet Monitoring:
config
context ingress
bfd-protocol
bfd multihop-peer 41.41.41.2 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 42.42.42.2 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 43.43.43.2 interval 50 min_rx 50 multiplier 20
#exit
interface TS_SecNet_v4 loopback
ip address 41.41.41.1 255.255.255.255
#exit
interface TS_SecNet_v4_1 loopback
ip address 42.42.42.1 255.255.255.255
#exit
interface TS_SecNet_v4_2 loopback
ip address 43.43.43.1 255.255.255.255
#exit
interface TS_Secnet_ingress
ip address 41.0.0.249 255.255.255.252
#exit
interface TS_Secnet_ingress1
ip address 41.0.0.253 255.255.255.252
#exit
interface TS_Secnet_ingress2
ip address 41.0.0.245 255.255.255.252
#exit

ip route static multihop bfd bfd1 41.41.41.1 41.41.41.2

ip route static multihop bfd bfd2 42.42.42.1 42.42.42.2
ip route static multihop bfd bfd3 43.43.43.1 43.43.43.2
ip route 41.41.41.2 255.255.255.255 41.0.0.250 TS_Secnet_ingress
ip route 42.42.42.2 255.255.255.255 41.0.0.254 TS_Secnet_ingress1
ip route 43.43.43.2 255.255.255.255 41.0.0.246 TS_Secnet_ingress2
#exit
end
config
context egress
bfd-protocol
bfd multihop-peer 41.41.41.1 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 42.42.42.1 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 43.43.43.1 interval 50 min_rx 50 multiplier 20

#exit
interface TS_SecNet_v4 loopback
ip address 41.41.41.2 255.255.255.255
#exit
interface TS_SecNet_v4_1 loopback
ip address 42.42.42.2 255.255.255.255
#exit
interface TS_SecNet_v4_2 loopback
ip address 43.43.43.2 255.255.255.255
#exit
interface TS_Secnet_egress
ip address 41.0.0.250 255.255.255.252
#exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
412
 Cisco Confidential - Limited Release
NSH Traffic Steering
N to M Traffic Steering

interface TS_Secnet_egress1
ip address 41.0.0.254 255.255.255.252
#exit
interface TS_Secnet_egress2
ip address 41.0.0.246 255.255.255.252
#exit
subscriber default
exit
aaa group default
#exit
ip route static multihop bfd bfd4 41.41.41.2 41.41.41.1
ip route static multihop bfd bfd5 42.42.42.2 42.42.42.1
ip route static multihop bfd bfd6 43.43.43.2 43.43.43.1
ip route 41.41.41.1 255.255.255.255 41.0.0.249 TS_Secnet_egress
ip route 42.42.42.1 255.255.255.255 41.0.0.253 TS_Secnet_egress1
ip route 43.43.43.1 255.255.255.255 41.0.0.245 TS_Secnet_egress2
#exit
end

One sample interface configuraition to bind all interfaces to port and vlan.
port ethernet 1/11
vlan 1608
no shutdown
bind interface TS_Secnet_ingress ingress
#exit
vlan 1609
no shutdown
bind interface TS_Secnet_ingress1 ingress
#exit
vlan 1610
no shutdown
bind interface TS_Secnet_ingress2 ingress
#exit
#exit
port ethernet 1/13
no shutdown
vlan 1608
no shutdown
bind interface TS_Secnet_egress egress
#exit
vlan 1609
no shutdown
bind interface TS_Secnet_egress1 egress
#exit
vlan 1610
no shutdown
bind interface TS_Secnet_egress2 egress
#exit

service schema configuration:

trigger-action ta1
up-service-chain sc_owm
#exit
trigger-action default
up-service-chain default
#exit
trigger-condition tc1
rule-name = udp
rule-name = http-pkts
rule-name = tcp
rule-name = dynamic2
multi-line-or all-lines
#exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
413
 Cisco Confidential - Limited Release
NSH Traffic Steering
N to M Traffic Steering

trigger-condition tc2
rule-name = qci8
rule-name = qci1
multi-line-or all-lines
#exit
trigger-condition defualt
any-match = TRUE
#exit
service-scheme scheme1
trigger rule-match-change
priority 1 trigger-condition tc1 trigger-action ta1
priority 2 trigger-condition tc2 trigger-action ta1
#exit
trigger subs-scheme-received
priority 1 trigger-condition default trigger-action default
#exit
#exit
subs-class class1
subs-scheme = gold
#exit
subscriber-base base1
priority 1 subs-class class1 bind service-scheme scheme1
#exit

• Host Specific configuration: The following configurations is the part of the host specific configuration.
• TS-bind IP configuration for each ACTIVE UP is the part of host specific configuration on RCM.

svc-type upinterface
redundancy-group 1
host Active1
host 391 " context ISP1-UP"
host 436 " interface ISP1_TO_PDN_v6 loopback"
host 437 " ipv6 address 4000::106/128"
host 438 " #exit"
host 439 " interface ISP1_TO_PDN_v4 loopback"
host 440 " ip address 40.0.0.106 255.255.255.255"
host 441 " #exit"
host 471 "ts-bind-ip up1 ipv4-address 40.0.0.106 ipv6-address 4000::106"
host 472 " exit"
host Active2
host 600 " context ISP1-UP"
host 601 " interface ISP1_TO_PDN_v6 loopback"
host 602 " ipv6 address 4000::107/128"
host 603 " #exit"
host 604 " interface ISP1_TO_PDN_v4 loopback"
host 605 " ip address 40.0.0.107 255.255.255.255"
host 606 " #exit"
host 607 "ts-bind-ip up2 ipv4-address 40.0.0.107 ipv6-address 4000::107"
host 608 " exit"

Note TS-bind IP is a loopback IP address. Its physical IP address is the part of Day-0
configuration.

• Common configuration: The following configuration is the part of the common configuration.
• Traffic steering configuration (up-nsh format, up-appliance-group, and up-service-chain config).

nsh
up-nsh-format owm-format

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
414
 Cisco Confidential - Limited Release
NSH Traffic Steering
N to M Traffic Steering

tag-value 7 imsi encode

tag-value 4 rating-group encode
tag-value 1 stream-fp-md encode decode
tag-value 2 reverse-stream-fp-md encode decode
tag-value 76 subscriber-profile encode
tag-value 3 secondary-srv-path-hdr encode
tag-value 5 rat-type encode
tag-value 51 mcc-mnc encode
tag-value 255 apn encode
tag-value 25 sgsn-address encode
#exit

#exit
traffic-steering
up-appliance-group secure-net
steering-type l2-mpls-aware
min-active-instance 1
instance 1 ingress slot/port 1/12 vlan-id 1608 egress slot/port 1/13 vlan-id 1608
ingress-context ingress ip address 41.41.41.1egress-context egress ip address 41.41.41.2
load-capacity 100
instance 2 ingress slot/port 1/12 vlan-id 1609 egress slot/port 1/13 vlan-id 1609
ingress-context ingress ip address 42.42.42.1egress-context egress ip address 42.42.42.2
load-capacity 80
instance 3 ingress slot/port 1/12 vlan-id 1610 egress slot/port 1/13 vlan-id 1610
ingress-context ingress ip address 43.43.43.1egress-context egress ip address 43.43.43.2
load-capacity 90
exit
up-appliance-group owm_only
steering-type nsh-aware
up-nsh-format new
min-active-instance 1
instance 1 ip address 40.40.40.100 load-capacity 80
instance 2 ip address 40.40.40.101 load-capacity 90
#exit

up-service-chain sc_owm
sfp-id 1 direction uplink up-appliance-group secure-net instance 1
up-appliance-group owm_only instance 2
sfp-id 2 direction downlink up-appliance-group owm_only instance 2
up-appliance-group secure-net instance 1
sfp-id 10 direction uplink up-appliance-group secure-net instance 2
up-appliance-group owm_only instance 2
sfp-id 11 direction downlink up-appliance-group owm_only instance 2
up-appliance-group secure-net instance 2
sfp-id 12 direction uplink up-appliance-group secure-net instance 3
up-appliance-group owm_only instance 2
sfp-id 13 direction downlink up-appliance-group owm_only instance 2
up-appliance-group secure-net instance 3
sfp-id 14 direction uplink up-appliance-group secure-net instance 1
up-appliance-group owm_only instance 1
sfp-id 15 direction downlink up-appliance-group owm_only instance 1
up-appliance-group secure-net instance 1
sfp-id 16 direction uplink up-appliance-group secure-net instance 2
up-appliance-group owm_only instance 1
sfp-id 17 direction downlink up-appliance-group owm_only instance 1
up-appliance-group secure-net instance 2
sfp-id 18 direction uplink up-appliance-group secure-net instance 3
up-appliance-group owm_only instance 1
sfp-id 19 direction downlink up-appliance-group owm_only instance 1
up-appliance-group secure-net instance 3
#exit
up-service-chain default
sfp-id 200 direction uplink up-appliance-group owm_only instance 1
sfp-id 201 direction downlink up-appliance-group owm_only instance 1

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
415
 Cisco Confidential - Limited Release
NSH Traffic Steering
Interworking with Inline Features

sfp-id 202 direction uplink up-appliance-group owm_only instance 2

sfp-id 203 direction downlink up-appliance-group owm_only instance 2
#exit
commit
exit

Show CLI for Verification

Following are the show CLIs for User Plane and RCM:
• User Plane: Show srp checkpoints stats/ Show srp checkpoints stats debug-info
laas-setup# show srp checkpoint statistics | grep UPLANE_TRAFFIC_STEERING_INFO

• RCM : under rcm checkpoint manager

"numTSInfo": 0

Interworking with Inline Features

Support for interworking with the following inline features is not in the scope of the existing implementation.
• IPv4/v6 Readdressing
• NAT44 and NAT64
• Next Hop Forwarding
• L2 Marking

The encoding of rating group in the NSH context header is supported aligned with the following expected
behaviour:
• The encoded rating group value corresponds to the rule that each packet matches. So, in a single flow’s
packets, the rating group either changes or is not encoded as the flow moves across different rules with
different rating groups configured/or not configured.
• The SAEGW populates the rating group value, if configured, in the rating group field. If only content id
is configured then this value is populated in the field. In the event that none are associated with the
packet’s matching rule, no TLV field corresponding to the rating group is sent.
• In case SAE-GW performs a deferred rule match and send out the packets without a rule match, it doesn't
encode the rating group TLV for such packets.

Monitoring and Troubleshooting

This section describes how to monitor and troubleshoot this feature.

Show Commands for Control Plane

This section describes the available show command to monitor this feature on CP.
show active-charging sessions full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
416
 Cisco Confidential - Limited Release
NSH Traffic Steering
Monitoring and Troubleshooting

Note TS Subscription Scheme Name: Displays the subscription scheme that must be applied from the service-scheme
configured under the active-charging-service. This active-charging-service is received from PCRF over the
Gx interface.

Show Commands for User Plane

This section describes the available show commands to monitor this feature on UP.
Show Commands for Configuration
This section describes the available show commands to check configuration for the feature.
• show user-plane-service traffic-steering up-service-chain all
• show user-plane-service traffic-steering up-service-chain name up-service-chain name
• show user-plane-service traffic-steering up-service-chain sfp-id sfp-id

Show Commands for Data Statistics

This section describes the available show commands to check data statistics related to the feature.
• show user-plane-service inline-services traffic-steering statistics up-service-chain all v
• show user-plane-service inline-services traffic-steering statistics up-service-chain all
• show user-plane-service inline-services traffic-steering statistics up-service-chain sfp-id sfp-id
• show user-plane-service inline-services traffic-steering statistics up-appliance-group all verbose
• show user-plane-service inline-services traffic-steering statistics up-appliance-group name appliance
group name
• show user-plane-service inline-services traffic-steering statistics up-appliance-group name appliance
group name instance appliance instance

Show Commands to Check the Service Chain and SFP Association for TS:
This section describes the available show commands to check the service chain and SFP association.
• show subscriber user-plane-only flows
• show subscribers user-plane-only callid <call-id> flows

Show Commands for OAM Statistics

This section describes the available show commands to check OAM statistics related to the feature.
• show user-plane-service inline-services traffic-steering oam all
• show user-plane-service inline-services traffic-steering oam summary
• show user-plane-service inline-services traffic-steering oam l3-steering summary
• show user-plane-service inline-services traffic-steering oam l3-steering monitors <ip address>
• show user-plane-service inline-services traffic-steering oam l3-steering monitors all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
417
 Cisco Confidential - Limited Release
NSH Traffic Steering
Monitoring and Troubleshooting

• show user-plane-service inline-services traffic-steering oam l3-steering monitors

up-appliance-group<name>
• show user-plane-service inline-services traffic-steering oam l2-steering monitors all
• show user-plane-service inline-services traffic-steering oam l2-steering monitors up-appliance-group
<name>
• show user-plane-service inline-services traffic-steering oam l2-steering summary
• clear user-plane-service traffic-steering oam statistics
• clear user-plane-service traffic-steering oam l3-steering statistics

Currently BFD doesn’t provide an API to clear session stats, so the following traffic-steering OAM clear
command is extended to include l2-steering stats.
• clear user-plane-service traffic-steering
• OAM - Clears OAM
• statistics - Clears the User-Plane Traffic-steering Statistics

• clear user-plane-service traffic-steering OAM

• L3-steering - Clear L3-steering OAM
• statistics - Clears OAM statistics

Show Configuration Command

The following configuration is a snippet of a sample show configuration command for this feature.

nsh
up-nsh-format format4
tag-value 250 imsi encode
tag-value 66 msisdn encode
tag-value 4 rating-group encode
tag-value 1 stream-fp-md encode decode
tag-value 2 reverse-stream-fp-md encode decode
tag-value 76 subscriber-profile encode
tag-value 3 secondary-srv-path-hdr encode
tag-value 5 rat-type encode
tag-value 51 mcc-mnc encode
tag-value 255 apn encode
tag-value 25 sgsn-address encode
#exit
traffic-steering
up-service-chain owm
sfp-id 65535 direction uplink up-appliance-group owm instance 1
sfp-id 65536 direction downlink up-appliance-group owm instance 2
sfp-id 65537 direction downlink up-appliance-group owm instance 1
sfp-id 65538 direction uplink up-appliance-group owm instance 2
#exit
up-service-chain sc_owm
sfp-id 9 direction uplink up-appliance-group secure-net instance 1 up-appliance-group
owm instance 1
sfp-id 10 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 1
sfp-id 11 direction uplink up-appliance-group secure-net instance 2 up-appliance-group

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
418
 Cisco Confidential - Limited Release
NSH Traffic Steering
Monitoring and Troubleshooting

owm instance 1
sfp-id 12 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 2
sfp-id 13 direction uplink up-appliance-group secure-net instance 1 up-appliance-group
owm instance 2
sfp-id 14 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 1
sfp-id 15 direction uplink up-appliance-group secure-net instance 2 up-appliance-group
owm instance 2
sfp-id 16 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 2
sfp-id 17 direction uplink up-appliance-group secure-net instance 3 up-appliance-group
owm instance 1
sfp-id 18 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 3
sfp-id 19 direction uplink up-appliance-group secure-net instance 4 up-appliance-group
owm instance 1
sfp-id 20 direction downlink up-appliance-group owm instance 1 up-appliance-group
secure-net instance 4
sfp-id 21 direction uplink up-appliance-group secure-net instance 3 up-appliance-group
owm instance 2
sfp-id 22 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 3
sfp-id 23 direction uplink up-appliance-group secure-net instance 4 up-appliance-group
owm instance 2
sfp-id 24 direction downlink up-appliance-group owm instance 2 up-appliance-group
secure-net instance 4
#exit
up-appliance-group owm
steering-type nsh-aware
up-nsh-format format4
min-active-instance 1
instance 1 ip address 40.40.40.3
instance 2 ip address 4001::3
#exit
up-appliance-group secure-net
steering-type l2-mpls-aware
min-active-instance 1
instance 1 ingress slot/port 1/13 vlan-id 2136 egress slot/port 1/12 vlan-id 2136
ingress-context ingress ip address 4101::1 egress-context egress ip address 4101::2
load-capacity 100
instance 2 ingress slot/port 1/13 vlan-id 2137 egress slot/port 1/12 vlan-id 2137
ingress-context ingress ip address 4201::1 egress-context egress ip address 4201::2
load-capacity 60
instance 3 ingress slot/port 1/13 vlan-id 2138 egress slot/port 1/12 vlan-id 2138
ingress-context ingress ip address 4301::1 egress-context egress ip address 4301::2
load-capacity 20
instance 4 ingress slot/port 1/13 vlan-id 2139 egress slot/port 1/12 vlan-id 2139
ingress-context ingress ip address 4401::1 egress-context egress ip address 4401::2
load-capacity 100
#exit
#exit
ts-bind-ip nshsrcip ipv4-address 40.40.40.106 ipv6-address 4001::106
#exit
context egress
bfd-protocol
bfd multihop-peer 4101::1 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 4201::1 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 4301::1 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 4401::1 interval 50 min_rx 50 multiplier 20
#exit
interface ts_egress1
ipv6 address 4101::2/64
ip mtu 1600

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
419
 Cisco Confidential - Limited Release
NSH Traffic Steering
Monitoring and Troubleshooting

#exit
interface ts_egress2
ipv6 address 4201::2/64
ip mtu 1600
#exit
interface ts_egress3
ipv6 address 4301::2/64
ip mtu 1600
#exit
interface ts_egress4
ipv6 address 4401::2/64
ip mtu 1600
#exit
subscriber default
exit
aaa group default
#exit
gtpp group default
#exit
ipv6 route static multihop bfd bfd1 4101::2 4101::1
ipv6 route static multihop bfd bfd2 4201::2 4201::1
ipv6 route static multihop bfd bfd3 4301::2 4301::1
ipv6 route static multihop bfd bfd4 4401::2 4401::1
ip igmp profile default
#exit
#exit
context ingress
bfd-protocol
bfd multihop-peer 4101::2 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 4201::2 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 4301::2 interval 50 min_rx 50 multiplier 20
bfd multihop-peer 4401::2 interval 50 min_rx 50 multiplier 20
#exit
interface ts_ingress1
ipv6 address 4101::1/64
ip mtu 1600
#exit
interface ts_ingress2
ipv6 address 4201::1/64
ip mtu 1600
#exit
interface ts_ingress3
ipv6 address 4301::1/64
ip mtu 1600
#exit
interface ts_ingress4
ipv6 address 4401::1/64
ip mtu 1600
#exit
subscriber default
exit
aaa group default
#exit
gtpp group default
#exit
ipv6 route static multihop bfd bfd1 4101::1 4101::2
ipv6 route static multihop bfd bfd2 4201::1 4201::2
ipv6 route static multihop bfd bfd3 4301::1 4301::2
ipv6 route static multihop bfd bfd4 4401::1 4401::2
ip igmp profile default
#exit
#exit
context ISP1-UP
ip access-list IPV4ACL

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
420
 Cisco Confidential - Limited Release
NSH Traffic Steering
Monitoring and Troubleshooting

redirect css service ACS any

permit any
#exit
ipv6 access-list IPV6ACL
redirect css service ACS any
permit any
interface TO-ISP12
ipv6 address 4001::106/64
ip address 40.40.40.106 255.255.255.0 secondary
ip mtu 2000
#exit
port ethernet 1/12
no shutdown
vlan 2135
no shutdown
bind interface TO-ISP12 ISP1-UP
#exit
vlan 2136
bind interface ts_egress1 egress
#exit
vlan 2137
no shutdown
bind interface ts_egress2 egress
#exit
vlan 2138
no shutdown
bind interface ts_egress3 egress
#exit
vlan 2139
no shutdown
bind interface ts_egress4 egress
#exit
#exit
port ethernet 1/13
no shutdown
vlan 2137
no shutdown
bind interface ts_ingress2 ingress
#exit
vlan 2138
no shutdown
bind interface ts_ingress3 ingress
#exit
vlan 2139
no shutdown
bind interface ts_ingress4 ingress
#exit
vlan 2136
no shutdown
bind interface ts_ingress1 ingress
#exit
#exit

Show Command for User Plane 1:1 Redundency

show srp checkpoint statistics | grep ts-sfp
call-recovery-uplane-internal-audit-ts-sfp-failure: 0

Show Commands for SFP availability

show user-plane traffic-steering up-service-chain <all> <name> <sfp-id>

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
421
 Cisco Confidential - Limited Release
NSH Traffic Steering
SNMP Traps

SNMP Traps
The following SNMP Traps are added in support of this feature:
• UPlaneTsMisConfig : When there is no SFP that is associated with an appliance group.
• UPlaneTsNoSelectedSfp : When an SFP selection is not possible.
• UPlaneTsServiceChainOrApplianceDown : When a service chain or an application node becomes
unavailable. The service chain is unavailable when the minimum instance of application group becomes
unavailable.
• UPlaneTsServiceChainOrApplianceUp : When the node status of appliance is updated because the service
chain or application node instance becomes available.

Bulk Statistics
Up-service-chain Schema

Variable Name Data Type Counter Type Description

up-svc-chain-name String Info Name of up service chain
up-svc-chain-status Int32 Info Status of up service chain
up-svc-chain-load-status Int32 Gauge Load status of up service
chain
up-svc-chain-sfp- Int32 Counter SFP stickiness miss count
of up service chain
stickiness-miss-count

up-svc-chain-sfp-not- Int32 Counter SFP not selected count of

up service chain
selected-count

up-svc-chain-associated-calls Int32 Gauge Associated calls of up

service chain
up-svc-chain-associated-flows Int32 Gauge Associated flows of up
service chain
up-svc-chain-total-uplink-pkts Int64 Counter Total Uplink packets of
up service chain
up-svc-chain-total-uplink-bytes Int64 Counter Total Uplink bytes of up
service chain
up-svc-chain-total-downlink-pkts Int64 Counter Total Downlink packets
of up service chain
up-svc-chain-total-downlink-bytes Int64 Counter Total Downlink bytes of
up service chain

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
422
 Cisco Confidential - Limited Release
NSH Traffic Steering
Bulk Statistics

Up-appliance-group Schema

Variable Name Data Counter Description

Type Type
up-appl-group-name String Info Name of up Appliance Group
up-appl-group-status Int32 Info Status of up appliance group
up-appl-group-load-status Int32 Gauge Load status of up appliance group
up-appl-group-node-down-count Int32 Counter Node down count of up appliance group
up-appl-group-associated-sfps Int32 Gauge Associated sfps of up appliance group
up-appl-group-num-times-loaded-state Int32 Counter Number of times node down state of up
appliance group
up-appl-group-total-uplink-pkts Int64 Counter Total Uplink packets of up appliance group
up-appl-group-total-uplink-bytes Int64 Counter Total Uplink bytes of up appliance group
up-appl-group-total-downlink-pkts Int64 Counter Total Downlink packets of up appliance
group
up-appl-group-total-downlink-bytes Int64 Counter Total Downlink bytes of up appliance group

The following CLI command is a sample bulkstats configuration for the feature.
config
bulkstats collection
bulkstats mode
file 1
up-service-chain schema TS format "\nup-service-chain-name = %up-svc-chain-name%
\nup-service-chain-status=%up-svc-chain-status%\nup-service-chain-load-status =
%up-svc-chain-load-status%\nup-service-chain-associated-calls =
%up-svc-chain-associated-calls%\nup-service-chain-associated-flows =
%up-svc-chain-associated-flows%\nup-service-chain-total-uplink-pkts =
%up-svc-chain-total-uplink-pkts%\nup-service-chain-total-uplink-bytes =
%up-svc-chain-total-uplink-bytes%\nup-service-chain-total-downlink-pkts =
%up-svc-chain-total-downlink-pkts%\nup-service-chain-total-total-downlink-bytes
= %up-svc-chain-total-downlink-bytes%\n\n"

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
423
 Cisco Confidential - Limited Release
NSH Traffic Steering
Bulk Statistics

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
424
 Cisco Confidential - Limited Release

CHAPTER 54
Packet Flow Description Management Procedure
for Static and Predefined Rules
• Feature Description, on page 425
• How It Works, on page 425
• Monitoring and Troubleshooting, on page 435

Feature Description
The Packet Flow Description Management Procedure feature allows control plane to configure static and
predefined rules and other charging information on the User Plane.

How It Works
Prior to CUPS, static and predefined rule processing was dependent on Rule-Def, Rule-Base, and
Charging-Action. Rules-Base indicates the priority in which order static rules are needed to be matched and
also provide associated charging action.
With the CUPS architecture, to process L3/L4 static and predefined rules, rule-def, rule-base, and
charging-action need to be available at the User Plane. Using the PFD management message, control plane
sends all this information to the associated User Plane.
To send this information from Control Plane to User Plane, CUPS architecture uses the following two modules:
• Sx-U Demux: Handles all node level messages with different Control-Plane nodes.
• Sx-C Demux: Handles node level message exchange with User-Plane service, that is, PFD management
messages, Sx-association messages, Heartbeat related messages.

1. Once the Control-Plane is initialized with all the configuration and User-Plane is initialized with initial
configuration, the PFD management request message is initiated using the debug mode CLI command.
See to the Monitoring and Troubleshooting section for the debug command.
2. Once the debug CLI command is executed, the Sx-C demux pushes all the Rule-Def, Rule-Base, and
Charging-Action configuration to the User-Plane using PFD management request or response message.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
425
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Moving Bulk Configurations from Control Plane to User Plane

3. After the Sx-U demux on the User-Plane receives the PFD management request message, it decodes the
configuration and sends it to each session manager instance at the User-Plane node and stores it in the
SCT.

Moving Bulk Configurations from Control Plane to User Plane

A set of configurations can be pushed from the Control Plane (CP) to the User Plane (UP) using the push
config-to-up all CLI command. A configuration timer constantly runs at the session controller. On expiration
of this timer, various types of configurations in bulk are pushed to all designated session managers. The session
controller maintains skip lists of various configuration types received from the CP. As and when the Sx Demux
pushes the configuration, they are stored in skip lists based on the configuration type.
When the skip list reaches its maximum length, the entire list - for a particular configuration type, is pushed
from the session controller to all session managers. This provision reduces the number of messenger
events/messages between proclets as the configurations are sent in a single message rather than sending one
message for each configuration.
The following configuration types supported for a bulk configuration push:
• Ruledef
• Charging Action
• Action Priority Lines
• Routing Rule configuration
• Group of Ruledef configuration
• Rule in Group of Ruledef configuration
• Rulebase L3/L4/L7 Info configuration
• APN configuration
• ACS Service configuration
• Service Chain configuration
• NSH Format
• NSH Field
• Traffic Steering Group
• Host pool configuration in ECS
• Port Map configuration in ECS
• Service scheme framework configuration in ECS
• X-header format in ECS
• Content filtering category Policy IDs in ECS

Currently, configuration propagation from CP to UP occurs only when Sx Association happens between CP
and UP upon UP registration, or when push config-to-up all CLI is triggered. During configuration propagation,
all the configurations are pushed from CP to UP. After UP registration occurs, when a new configuration is

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
426
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Moving Bulk Configurations from Control Plane to User Plane

added or existing configuration is modified, the UP has to be rebooted for registration to receive the updated
configuration from CP. This is because configuration updates are not propagated to UP for now.
When the push config-to-up all CLI is executed, the entire configuration is propagated to all the
registered/associated UPs. The configuration can be propagated to a specific UP as well by giving the peer
address as input. The configuration is pushed only to UPs that are associated with the CP.
The push config-to-up all CLI does not delete any existing configuration on the UP and also does not flush
out any unwanted configuration in UP, which is not present in CP. The configuration from CP merges with
what is currently present in UP. The existing configuration on UP is not flushed out. The configuration audit
between CP and UP is not supported.
Rule, Rulebase action priority, Host pool, and Port Map removal through configuration on CP leads to automatic
push from CP to UP. Rule addition or modification requires push through the CLI.
Support for rule-lines modifications (addition or deletion) are added in the ruledef. The changed rule-lines
are the candidate for rule matching for the existing flows, the new flows, or the new calls.
In CUPS (without RCM), modifications are done in Control Plane and pushed to User Plane via PFD
mechanism. In CUPS (with RCM), changes are done in RCM and pushed to User Plane. Changes are done
parallelly and separately in Control Plane.
The following table provides information about the impact of configuration change in new and existing calls.

Change in Configuration Impact on existing calls Impact on existing calls Impact on new calls
(existing flows) (new flows)

Existing Ruledef Rule match is enforced on The configuration changes The configuration changes
contents/New Rule existing flows after apply on new flows. For apply on new calls. For
addition configuration change. new flows, anyways fresh new flows, anyways fresh
rule match would happen rule match would happen
and the ruledef changes and the ruledef changes
are applied on new flows are applied on flows for
for existing calls new calls.

No Ruledef Rule in use cannot be Rule match is enforced on The configuration changes
deleted unless its action existing flows after apply on new calls.
priority is deleted from configuration change.
the rulebase.

New Group of Ruledefs Rule match is enforced on The configuration changes The configuration changes
(GoR)/Changes to existing flows after apply on new flows. For apply on new calls. For
existing Group of configuration change. new flows, anyways fresh new flows, fresh rule
Ruledefs contents (Add or rule match would happen match would happen, and
Delete Rule in GoR) and the GoR changes are the GoR changes are
applied on new flows for applied on flows for new
existing calls. calls.

No GoR Rule in use cannot be Rule match is enforced on The configuration changes
deleted unless its action existing flows after apply on new calls.
priority is deleted from configuration change.
the rulebase.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
427
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Limitation

Change in Configuration Impact on existing calls Impact on existing calls Impact on new calls
(existing flows) (new flows)

No Rule in GoR Rule match is enforced on New flows go through a New flows go through a
existing flows after fresh rule match and fresh rule match and
configuration change. configuration change configuration change
takes effect. takes effect.

Action Priority Configuration changes Configuration changes Configuration changes

Changes/Action Priority apply on existing flows. apply on new flows. apply on new calls.
addition

No Action Priority Configuration changes Configuration changes Configuration changes

apply on existing flows. apply on new flows. apply on new calls.

No-Rulebase No-Rulebase is not No-Rulebase is not No-Rulebase is not

supported. supported supported

No-APN No-APN is not supported No-APN is not supported No-APN is not supported

IP source violation No impact on existing No impact on existing Configuration changes

calls calls apply on new calls.

Limitation
When CP is on VPC-DI, delay in PFD configuration push from CP to UP may be observed on systems with
bulk configurations in CP that is connected to large number of UPs.
The delay is caused as VPC-DI is a multi-card chassis, with an inter-card communication process, that takes
some time to fetch configurations from Shared/System Configuration Task (SCT) for each peer UP.
When CP is on VPC-SI, the delay is not observed.

Sx Association

Important This feature is not fully qualified in this release. It is available only for testing purposes. For more information,
contact your Cisco Accounts representative.

In CUPS environment, the Control Plane and User Plane entity should perform association with each other
before establishing communication.
The Sx Association procedure is defined in 3GPP TS 29.244. As these are node level messages, they are
handled by Sx-C Demux on Control Plane and Sx-U Demux on User Plane.
Call Flow

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
428
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Sx Association

Following is a brief overview of how Sx Association works:

1. Sx Association Setup Request is initiated by Control Plane or User Plane.

Important In this release, only Sx Association Setup Request from User Plane is supported.

2. For User Plane to initiate Sx Association Setup Request, Operator should configure control-plane-group
at Global Configuration mode and associate control-plane-group to User Plane Service. Refer Configuring
Sx Association Setup Request section of this chapter.
3. Peer node ID (which is, currently, either IPv4 or IPv6 address) is configured in control-plane-group.
4. Currently, on User Plane, the Sx-U Demux uses Sx-Service Address (as it is on Node Id) which is sent
into Sx Association Setup Request. Selection of IPv4 and IPv6 is depended on the configured peer-node-id.
5. After User Plane Service is up on User Plane, Sx-U Demux sends Sx Association Request toward Control
Plane. Sx-C Demux validates and sends Sx Association Response toward User Plane.
6. After Control Plane processes Sx Association Request and sends response to User Plane, it starts Prime
PFD message toward User Plane to send the configuration. Also, Control Plane starts Heartbeat procedure
with the associated User Plane.
7. After receiving Sx Association Response, User Plane also starts Heartbeat procedure toward Control
Plane.
8. If Control Plane is not ready (SAEGW Service is not up) when it receives Sx Association Setup Request,
it rejects the Sx Association Setup Request. The User Plane reattempts Sx Association Set-up Request

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
429
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Configuring Control Plane Group

after association reattempt-timeout. Refer the Configuring Sx Association Reattempt Timeout section
of this chapter.

Release of Sessions for a Specific User Plane

To bring down a specific User Plane, it is recommended to first clear all subscribers that belong to that User
Plane using the following CLI command:
clear subscribers saegw-only uplane-address user_plane_address no-select-up
Executing this CLI command releases all sessions that belong to the mentioned User Plane, gracefully, and
marks that User Plane as "Not Available for Session Selection". This User Plane remains in Associated state
but it will not be available for Session selection.
After clearing the session, execute either of the following CLI command on User Plane to remove its association
from Control Plane.
no user-plane-service service_name

Or
no peer-node-id { ipv4-address ipv4_address | ipv6-address ipv6_address }
For additional information about the above CLI commands, refer Configuring User Plane Service and
Configuring Peer Node ID sections in this guide.
To release only the existing sessions from a User Plane, use the following CLI command:
clear subscribers saegw-only uplane-address user_plane_address

Please note that in this case, the User Plane remains in Associated state and available for Session selection.

ICSR Support
For Sx-Control Plane, Demux ICSR is supported. All associated Peer information is checkpointed to Standby
Chassis Sx-Control Plane Demux through the Session manager.

Demux Recovery Support

Sx-Control Plane Demux recovery and unplanned Demux card migration is supported. During recovery, all
associated Peer information is recovered from the Session manager to Sx-Control Plane Demux.
Currently, after Sx-Demux recovery, the Sx-Control Plane Demux does not perform audit with respective
VPNmgr for peer entries and Peer ID. In case of any error, it can lead to call drop and out-of-sync situation
between VPNMgr and SxMgr related to IP pool management and UP selection.

Configuring Control Plane Group

Use the following CLI commands to configure Control Plane Group under Global Configuration mode. The
Control Plane Group lists the Control Plane endpoints to which the User Plane will be associated
configure
[ no ] control-plane-group control_plane_group_name
end
NOTES:
• control-plane-group control_plane_group_name: Configures Control Plane Group on User Plane. The
control_plane_group_name should be a string of size 1 to 63.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
430
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Configuring Sx Association

• If previously configured, use the no control-plane-group control_plane_group_name CLI command

to remove the Control Plane Group configuration

Configuring Sx Association
This sections describes the CLI commands available in support of this feature.

Configuring Sx Association Setup Request

Use the following CLI commands to enable the attributes related to Peer Node IDs and Sx Association under
Control Plane Group Configuration mode.
configure
control-plane-group control_plane_group_name
sx-association { initiated-by-cp | initiated-by-up }
end
NOTES:
• sx-association: Configures Sx Association Setup Request that is initiated by Control Plane or User Plane.
The default value is initiated-by-up.
• initiated-by-cp: Sx Association Setup Request will be initiated by Control Plane.

Important This keyword is not supported in this release.

• initiated-by-up: Sx Association Setup Request will be initiated by User Plane.

Associating Control Plane Group with User Plane Service

Important Associating Control Plane Group with User Plane service is an optional parameter for User Plane service to
come up. If there is Control Plane Group that is associated with User Plane, and as per its configuration it is
supposed to start a Sx association, then the User Plane sends Sx Association Request to the defined Control
Plane endpoint.

Use the following CLI commands to associate User Plane service with Control Plane Group.
configure
contextcontext_name
user-plane-service service_name
[ no ] associate control-plane-group control_plane_group_name
end
NOTES:
• no: Removes Control Plane Group association from User Plane service.
• control-plane-group control_plane_group_name: Associates Control Plane Group with which User
Plane service performs Sx Association. The Control Plane Group name should be a string of size 1 to
63.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
431
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Configuring Peer Node ID

For more information about User Plane Service Configuration mode and it's relevant CLI commands, refer
the Configuring User Plane in CUPS chapter.

Configuring Peer Node ID

Use the following CLI commands to configure Control Plane node IDs.
configure
control-plane-group control_plane_group_name
[ no ] peer-node-id { ipv4-address ipv4_address | ipv6-address ipv6_address
}
end
NOTES:
• no: Removes the followed option.
• ipv4-address: Configures IPv4 address.
• ipv6-address: Configures IPv6 address (supports colon-separated hexadecimal notation).
• The peer-node-id is the Control Plane sx-service address which should be started, and should receive
and answer Setup requests.
• Currently, five node IDs can be added to the Control Plane group.

Configuring Sx Association Reattempt Timeout

Use the following configurations for Association Reattempt Timeout for Sx service.
configure
context context_name
sx-service service_name
sx-protocol association reattempt-timeout timeout_seconds
end
NOTES:
• association: Configures Sx Association parameters.
• reattempt-timeout timeout_seconds: Configures the Association Reattempt timeout for Sx Service, in
seconds, ranging from 30 to 300. Default is 60.
• After User Plane starts, it waits for 2 minutes on SSI and 10 minutes on ASR 5500 to start Association
Setup with Control Plane. This is done to make sure that the User Plane system is fully ready to handle
configuration messages that are sent from the Control Plane after Association Setup. These values can
be changed using reattempt-timeout.

Configuring Sx Association SNMP Traps

When an Sx association is detected, an SNMP trap (notification) is automatically generated by the system.
Use the following configuration to enable an SNMP trap when an Sx association is detected:
configure
snmp trap enable SxPeerAssociated
end
Use the following configuration to enable an SNMP trap when there is a Sx association release::

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
432
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Moving Bulk Configurations from Control Plane to User Plane

configure
snmp trap enable SxPeerAssociationRelease
end

Moving Bulk Configurations from Control Plane to User Plane

Use the following configuration to move bulk configurations from Control Plane to User Plane:
push config-to-up all peer-ip-addrIP_Address
NOTES:
• all: Pushes the configurations to all associated User Planes.
• peer-ip-addr: Pushes the configurations to a specified User Plane. The User Plane should be associated
to receive the configuration.IP_Address (IPv4 or IPv6) specifies the IP address of the User Plane node.
• IP Pool related configurations are not pushed using the above configuration.

Monitoring and Troubleshooting Sx Association

This section provides information about CLI commands available for monitoring and troubleshooting the Sx
Association procedure.

SNMP Trap
The following traps are available to track the status of an Sx Association:
• sn_trap_sx_peer_node_associated: An information trap which is triggered when an Sx association is
detected. The following information is shared with both Control Plane and User Plane:
• Context Name
• Service Name
• Node Type
• Node ID
• Peer Node Type
• Peer Node ID
• Group-Name

• sn_trap_sx_peer_node_association_release: An information trap which is triggered when an Sx

association release is detected. The following information is shared with both Control Plane and User
Plane:
• Context Name
• Service Name
• Node Type
• Node ID
• Peer Node Type
• Peer Node ID

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
433
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
Show Commands and/or Outputs

• Group-Name

Show Commands and/or Outputs

This section provides information regarding show commands and/or their outputs in support of Sx Association.

show control-plane-group all

The ouput of this show command displays fields in support of Sx Association.
• Control Plane Group
• Name:
• Sx-Association:
• Node-Id:
• Node-Id:

show user-plane-service name <name>

The output of this show command displays the following fields in support of Sx Association.
• Service name
• Service-Id
• Context
• Status
• PGW Ingress GTPU Service
• SGW Ingress GTPU Service
• SGW Egress GTPU Service
• Control Plane Tunnel GTPU Service
• Sx Service
• Control Plane Group

show sx peers
The output of this show command displays the fields in support of Sx Association.
• Node Type:
• (C) - CPLANE
• (U) - UPLANE

• Peer Mode:
• (A) - Active
• (S) - Standby

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
434
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show snmp trap history

• Association State:
• (i) - Idle
• (I) - Initiated
• (A) - Associated
• (R) - Releasing

• Configuration State:
• (C) - Configured
• (N) - Not Configured

• IP Pool:
• (E) - Enable
• (D) - Disable

• Sx Service ID
• Group Name
• Node ID
• Peer ID
• Recovery Timestamp
• No of Restart
• Current Sessions
• Max Sessions

show snmp trap history

The output of this command includes the following fields:
• Timestamp
• Trap Information

Monitoring and Troubleshooting

This section provides information regarding the debug command and show commands and/or their outputs
in support of this feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
435
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service charging-action all

show user-plane-service charging-action all

This command displays the following output:
Service Name: default
Charging Action Name: charge-action-qci8
Content ID: 0
Service ID: 0
EDRs: Disabled
EGCDRs: Enabled
Rf: Disabled
UDRs: Enabled
Flow Idle Timeout: 300 (secs)
Limit For Flow Type: Disabled
Bandwidth ID: 0
Limit For Uplink Bandwidth: Disabled
Limit For Downlink Bandwidth: Disabled
Throttle-Suppress Timeout: n/a
QoS Renegotiate Traffic-Class: Disabled
QoS Class Identifier: 8
IP Type of Service: Not Configured
Content Filtering: Enabled
Credit-Control: Disabled
Flow Action:
Redirect URL: Disabled
Redirect URL from OCS: Disabled
Redirect to Video Server: Disabled
Clear Quota Retry Timer: Disabled
Conditional Redirect: Disabled
Discard: Disabled
Terminate-Flow: Disabled
Terminate-Session: Disabled
Rulebase Change: Disabled
Billing Action:
Event Data Record: Disabled
GGSN charging Data Record: Enabled
Rf Accounting: Disabled
User Data Record: Enabled
Radius Accounting Record: Disabled
Charge Volume: ip bytes
PCO-Custom1 value: n/a
Flow-Mapping Idle Timeout: 300 (secs)
DNS Proxy Bypass: Disabled
Discard on Readdressing Failure: Disabled
Video Bitrate: Not Configured (default/no(0) is interpreted as bitrate=QOS MBR (GGSN/PGW))
Strip URL:
CAE-Readdressing: Disabled
TFT notification to UE : Enabled
Service Detection:
Session Update:
QOS: Disabled
Packet Filter Name
==================
Predefined Rule Deactivation: Disabled
Config URRID : 0x800050
Charging Action Name: charge-action-qci9
Content ID: 0
Service ID: 0
EDRs: Disabled
EGCDRs: Enabled
Rf: Disabled
UDRs: Enabled
Flow Idle Timeout: 300 (secs)
Limit For Flow Type: Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
436
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service charging-action all

Bandwidth ID: 0
Limit For Uplink Bandwidth: Disabled
Limit For Downlink Bandwidth: Disabled
Throttle-Suppress Timeout: n/a
QoS Renegotiate Traffic-Class: Disabled
QoS Class Identifier: 8
IP Type of Service: Not Configured
Content Filtering: Enabled
Credit-Control: Disabled
Flow Action:
Redirect URL: Disabled
Redirect URL from OCS: Disabled
Redirect to Video Server: Disabled
Clear Quota Retry Timer: Disabled
Conditional Redirect: Disabled
Discard: Disabled
Terminate-Flow: Disabled
Terminate-Session: Disabled
Rulebase Change: Disabled
Billing Action:
Event Data Record: Disabled
GGSN charging Data Record: Enabled
Rf Accounting: Disabled
User Data Record: Enabled
Radius Accounting Record: Disabled
Charge Volume: ip bytes
PCO-Custom1 value: n/a
Flow-Mapping Idle Timeout: 300 (secs)
DNS Proxy Bypass: Disabled
Discard on Readdressing Failure: Disabled
Video Bitrate: Not Configured (default/no(0) is interpreted as bitrate=QOS MBR (GGSN/PGW))
Strip URL:
CAE-Readdressing: Disabled
TFT notification to UE : Enabled
Service Detection:
Session Update:
QOS: Disabled
Packet Filter Name
==================
Predefined Rule Deactivation: Disabled
Config URRID : 0x800050
Charging Action Name: ggsn-ingress
Content ID: 10
Service ID: 0
EDRs: Disabled
EGCDRs: Disabled
Rf: Disabled
UDRs: Enabled
Flow Idle Timeout: 300 (secs)
Limit For Flow Type: Disabled
Bandwidth ID: 0
Limit For Uplink Bandwidth: Disabled
Limit For Downlink Bandwidth: Disabled
Throttle-Suppress Timeout: n/a
QoS Renegotiate Traffic-Class: Disabled
QoS Class Identifier: Not Configured
IP Type of Service: Not Configured
Content Filtering: Enabled
Credit-Control: Disabled
Flow Action:
Redirect URL: Disabled
Redirect URL from OCS: Disabled
Redirect to Video Server: Disabled
Clear Quota Retry Timer: Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
437
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service charging-action name charging-action-name

Conditional Redirect: Disabled

Discard: Disabled
Terminate-Flow: Disabled
Terminate-Session: Disabled
Rulebase Change: Disabled
Billing Action:
Event Data Record: Disabled
GGSN charging Data Record: Disabled
Rf Accounting: Disabled
User Data Record: Enabled
Radius Accounting Record: Disabled
Charge Volume: ip bytes
PCO-Custom1 value: n/a
Flow-Mapping Idle Timeout: 300 (secs)
DNS Proxy Bypass: Disabled
Discard on Readdressing Failure: Disabled
Video Bitrate: Not Configured (default/no(0) is interpreted as bitrate=QOS MBR (GGSN/PGW))
Strip URL:
CAE-Readdressing: Disabled
TFT notification to UE : Enabled
Service Detection:
Session Update:
QOS: Disabled
Packet Filter Name
==================
Predefined Rule Deactivation: Disabled
Config URRID : 0x800050
Total charging action(s) found: 3

show user-plane-service charging-action name charging-action-name

This command displays the following output:

Charging Action Name: charge-action-qci1

Content ID: 0
Service ID: 0
EDRs: Disabled
EGCDRs: Enabled
Rf: Disabled
UDRs: Enabled
Flow Idle Timeout: 300 (secs)
Limit For Flow Type: Disabled
Bandwidth ID: 0
Limit For Uplink Bandwidth: Disabled
Limit For Downlink Bandwidth: Disabled
Throttle-Suppress Timeout: n/a
QoS Renegotiate Traffic-Class: Disabled
QoS Class Identifier: 1
IP Type of Service: Not Configured
Content Filtering: Enabled
Credit-Control: Disabled
Flow Action:
Redirect URL: Disabled
Redirect URL from OCS: Disabled
Redirect to Video Server: Disabled
Clear Quota Retry Timer: Disabled
Conditional Redirect: Disabled
Discard: Disabled
Terminate-Flow: Disabled
Terminate-Session: Disabled
Rulebase Change: Disabled
Billing Action:
Event Data Record: Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
438
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service rule-base all

GGSN charging Data Record: Enabled

Rf Accounting: Disabled
User Data Record: Enabled
Radius Accounting Record: Disabled
Charge Volume: ip bytes
PCO-Custom1 value: n/a
Flow-Mapping Idle Timeout: 300 (secs)
DNS Proxy Bypass: Disabled
Discard on Readdressing Failure: Disabled
Video Bitrate: Not Configured (default/no(0) is interpreted as bitrate=QOS MBR (GGSN/PGW))
Strip URL:
CAE-Readdressing: Disabled
TFT notification to UE : Enabled
Service Detection:
Session Update:
QOS: Disabled
Packet Filter Name
==================
Predefined Rule Deactivation: Disabled
Config URRID : 0x800050
Total charging action(s) found: 1

show user-plane-service rule-base all

This command displays the following output:
Service Name: default
Rule Base Name: prepaid
Charging Action Priorities:
Name Type Priority Charging-action Timedef Description
============================================================================
rule-qci8 RD 1 charge-action-qci8 - -
rule-qci7 RD 2 charge-action-qci7 - -
rule-qci6 RD 3 charge-action-qci6 - -
rule-qci5 RD 4 charge-action-qci5 - -
rule-qci4 RD 5 charge-action-qci4 - -
rule-qci3 RD 6 charge-action-qci3 - -
rule-qci2 RD 7 charge-action-qci2 - -
rule-qci1 RD 8 charge-action-qci1 - -
rule-qci9 RD 9 charge-action-qci9 - -
ip-any-rule RS 11 ggsn-ingress - -
Post-processing Action Priorities:
Name Type Priority Charging-action Description
===========================================================================
Routing Action Priorities:
Ruledef Name Priority Analyzer Description
============================================================================
Groups of Prefixed Urls For Url Preprocessing :
EGCDR Fields:
Tariff time thresholds (min:hrs):
Interval Threshold : 0 (secs)
Uplink Octets : 0 Downlink Octets : 0
Total Octets : 0
Time Based Metering: Disabled
Content Filtering Group : Not configured
Content Filtering Policy : Not configured
Content Filtering Mode : Not configured
URL-Blacklisting Action : Not Configured
URL-Blacklisting Content ID : Not Configured
UDR Fields:
Interval Threshold : 0 (secs)
Uplink Octets : 0 Downlink Octets : 0
Total Octets : 0
First Hit Content-Id Trigger : Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
439
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service rule-base all

Tariff time trigger (min:hrs) : Disabled

NEMO-Prefix-Update Trigger : Disabled
CCA Fields:
RADIUS charging context: Not configured
RADIUS charging group : Not configured
RADIUS interim interval: Not configured
DIAMETER Requested Service Unit: Not configured
Quota Retry Time : 60 (secs)
Quota Holding Time (QHT): Not configured
Quota Time Duration Algorithms: Not configured
Flow End Condition : Disabled
Flow Any Error Charging Action: Disabled
Billing records : Disabled
Limit For Total Flows : Disabled
Limit For TCP Flows : Disabled
Limit For Non-TCP Flows : Disabled
FW-and-NAT Default Policy : n/a
PCP Service : n/a
QoS Renegotiation Timeout : Disabled
EDRs on DCCA Failure Handling : Disabled
EDRs on transaction complete : Disabled
Extract host from uri: Disabled
Tethering Detection : Disabled
OS-based Detection : N/A
UA-based Detection : N/A
Tethering Detection (ip-ttl) : Disabled
Max SYN detection in a flow : N/A
Tethering Detection (DNS-Based): Disabled
Tethering Detection (Application): Disabled
Websocket Flow-Detection Configuration:
n/a
Check-point Account Synchronization Timer Configuration:
SR : n/a
ICSR : n/a
EDR Suppress zero byte records : Disabled
EDR Timestamp Rounding : Round Off
EDR Charge Volume (sn-charge-volume)
Retransmissions counted : Enabled
Dropped counted : Disabled
EGCDR Timestamp Rounding : Round Off
RTP Dynamic Routing : Disabled
Ignore port number in application headers: Disabled
RTSP Delayed Charging : Disabled
Delayed Charging : Disabled
No Rating Group Override
No Service Id Override
IP Reassembly-Timeout : 5000 milliseconds
IP Reset ToS field : Disabled
IP Readdress Failure Terminate : Disabled
TCP Out-of-Order-Timeout : 5000 milliseconds
TCP Out-of-Order-Max-Entries : 1000 packets
TCP 2MSL Timeout : 2 sec Port Reuse: No
HTTP header parse limit : Disabled
RTSP initial bytes limit : Disabled
Xheader Certificate Name :
Xheader Re-encryption Period : 0 min
TCP MSS Modification : Disabled
TCP Check Window Size : Disabled
WTP Out-of-Order-Timeout : 5000 milliseconds
TCP transmit-out-of-order-packets : Immediately
WTP transmit-out-of-order-packets : Immediately
Verify Transport layer checksum : Enabled
ICMP Request Threshold : 20
Default Bandwidth-Policy : n/a

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
440
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service rule-base name rule-base-name

Bandwidth-Policy Fallback : Disabled

P2P Dynamic Routing : Disabled
TCP Proxy Mode Configuration:
TCP Proxy Mode : Disabled
CAE-Readdressing : Disabled
Transactional-Rule-Matching : Disabled
TRM Fastpath : Disabled
Override Control : Disabled
Override-Control-with-name : Disabled
Override-Control-with-grp-info : Disabled
Charging-Action Override : Disabled.
TFT notification to UE for default bearer : Enabled
Ran-Bandwidth Optimization : Disabled
Total rulebase(s) found: 1

show user-plane-service rule-base name rule-base-name

This command displays the following output:
Service Name: default
Rule Base Name: prepaid
Charging Action Priorities:
Name Type Priority Charging-action Timedef Description
============================================================================
rule-qci8 RD 1 charge-action-qci8 - -
rule-qci7 RD 2 charge-action-qci7 - -
rule-qci6 RD 3 charge-action-qci6 - -
rule-qci5 RD 4 charge-action-qci5 - -
rule-qci4 RD 5 charge-action-qci4 - -
rule-qci3 RD 6 charge-action-qci3 - -
rule-qci2 RD 7 charge-action-qci2 - -
rule-qci1 RD 8 charge-action-qci1 - -
rule-qci9 RD 9 charge-action-qci9 - -
ip-any-rule RS 11 ggsn-ingress - -
Post-processing Action Priorities:
Name Type Priority Charging-action Description
===========================================================================
Routing Action Priorities:
Ruledef Name Priority Analyzer Description
============================================================================
Groups of Prefixed Urls For Url Preprocessing :
EGCDR Fields:
Tariff time thresholds (min:hrs):
Interval Threshold : 0 (secs)
Uplink Octets : 0 Downlink Octets : 0
Total Octets : 0
Time Based Metering: Disabled
Content Filtering Group : Not configured
Content Filtering Policy : Not configured
Content Filtering Mode : Not configured
URL-Blacklisting Action : Not Configured
URL-Blacklisting Content ID : Not Configured
UDR Fields:
Interval Threshold : 0 (secs)
Uplink Octets : 0 Downlink Octets : 0
Total Octets : 0
First Hit Content-Id Trigger : Disabled
Tariff time trigger (min:hrs) : Disabled
NEMO-Prefix-Update Trigger : Disabled
CCA Fields:
RADIUS charging context: Not configured
RADIUS charging group : Not configured
RADIUS interim interval: Not configured
DIAMETER Requested Service Unit: Not configured

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
441
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service rule-base name rule-base-name

Quota Retry Time : 60 (secs)

Quota Holding Time (QHT): Not configured
Quota Time Duration Algorithms: Not configured
Flow End Condition : Disabled
Flow Any Error Charging Action: Disabled
Billing records : Disabled
Limit For Total Flows : Disabled
Limit For TCP Flows : Disabled
Limit For Non-TCP Flows : Disabled
FW-and-NAT Default Policy : n/a
PCP Service : n/a
QoS Renegotiation Timeout : Disabled
EDRs on DCCA Failure Handling : Disabled
EDRs on transaction complete : Disabled
Extract host from uri: Disabled
Tethering Detection : Disabled
OS-based Detection : N/A
UA-based Detection : N/A
Tethering Detection (ip-ttl) : Disabled
Max SYN detection in a flow : N/A
Tethering Detection (DNS-Based): Disabled
Tethering Detection (Application): Disabled
Websocket Flow-Detection Configuration:
n/a
Check-point Account Synchronization Timer Configuration:
SR : n/a
ICSR : n/a
EDR Suppress zero byte records : Disabled
EDR Timestamp Rounding : Round Off
EDR Charge Volume (sn-charge-volume)
Retransmissions counted : Enabled
Dropped counted : Disabled
EGCDR Timestamp Rounding : Round Off
RTP Dynamic Routing : Disabled
Ignore port number in application headers: Disabled
RTSP Delayed Charging : Disabled
Delayed Charging : Disabled
No Rating Group Override
No Service Id Override
IP Reassembly-Timeout : 5000 milliseconds
IP Reset ToS field : Disabled
IP Readdress Failure Terminate : Disabled
TCP Out-of-Order-Timeout : 5000 milliseconds
TCP Out-of-Order-Max-Entries : 1000 packets
TCP 2MSL Timeout : 2 sec Port Reuse: No
HTTP header parse limit : Disabled
RTSP initial bytes limit : Disabled
Xheader Certificate Name :
Xheader Re-encryption Period : 0 min
TCP MSS Modification : Disabled
TCP Check Window Size : Disabled
WTP Out-of-Order-Timeout : 5000 milliseconds
TCP transmit-out-of-order-packets : Immediately
WTP transmit-out-of-order-packets : Immediately
Verify Transport layer checksum : Enabled
ICMP Request Threshold : 20
Default Bandwidth-Policy : n/a
Bandwidth-Policy Fallback : Disabled
P2P Dynamic Routing : Disabled
TCP Proxy Mode Configuration:
TCP Proxy Mode : Disabled
CAE-Readdressing : Disabled
Transactional-Rule-Matching : Disabled
TRM Fastpath : Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
442
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service rule-def all

Override Control : Disabled

Override-Control-with-name : Disabled
Override-Control-with-grp-info : Disabled
Charging-Action Override : Disabled.
TFT notification to UE for default bearer : Enabled
Ran-Bandwidth Optimization : Disabled
Total rulebase(s) found: 1

show user-plane-service rule-def all

This command displays the following output:
Service Name: default
Ruledef Name: ip-any-rule
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci1
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci2
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci3
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci4
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci5
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci6
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Ruledef Name: rule-qci7
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
443
 Cisco Confidential - Limited Release
Packet Flow Description Management Procedure for Static and Predefined Rules
show user-plane-service rule-def name rule-def-name

show user-plane-service rule-def name rule-def-name

Service Name: default
Ruledef Name: rule-qci8
ip any-match = TRUE
Rule Application Type: Charging
Copy Packet to Log: Disabled
Tethered Flow Check: Disabled
Multi-line OR: Disabled
Total Ruledef(s) : 1

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
444
 Cisco Confidential - Limited Release

CHAPTER 55
PDI Optimization
• Feature Summary and Revision History, on page 445
• Feature Description, on page 445
• How It Works, on page 446
• Configuring the PDI Optimization Feature, on page 451
• PDI Optimization OAM Support, on page 452

Feature Summary and Revision History

Revision History
Revision Details Release
First introduced. 21.14
This feature is not fully qualified in this release.

Feature Description
The Packet Detection Information (PDI) Optimization feature allows the optimization of PFCP signaling,
through Sx Establishment and Sx Modification messages, between the Control Plane and the User Plane
function. Without PDI Optimization, the following common parameters are repeated in the PDI of all Packet
Detection Rules (PDRs), for a given bearer, resulting in an unwanted increase in signaling between Control
Plane and User Plane:
• Local F-TEID
• Network Instance
• UE IP address
• The PDI Optimization is achieved by consolidating the common parameters, in the PDI of the PDRs,
into a single container that is called the Traffic Endpoint (Traffic Endpoint ID). The consolidated
parameters from multiple PDRs are then referred to the Traffic Endpoint.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
445
 Cisco Confidential - Limited Release
PDI Optimization
Relationships

• The PDI Optimization is a CLI-controlled feature, and supported over the Sxa, Sxb, Sxc, Sxab, and N4
interfaces.

Relationships
The PDI Optimization feature is a prerequisite for the following features:
• GTP-U Error Indication Support on User Plane.
• Sx Bulkstats
• CUPS Bulkstats Support

How It Works
The Traffic Endpoint ID is unique within a PFCP session. When a PDI refers to a Traffic Endpoint, the
parameters that are in the Traffic Endpoint is not provided in the PDI once again. The Control Plane function
updates the Traffic Endpoint whenever applicable.
If a Traffic Endpoint is updated, all the PDRs that refer to this Traffic Endpoint in the User Plane function
uses the updated information.
If the F-TEID allocation is performed in the User Plane function, the User Plane function allocates and stores
the F-TEID associated to the Traffic Endpoint. When the User Plane function provides the allocated F-TEID
to the Control Plane function in the PFCP Session Establishment response or PFCP Session Modification
response message, the Control Plane function updates the Traffic Endpoint information that is stored in the
Control Plane function with the received F-TEID.
The Control Plane function uses the Traffic Endpoint ID created in a different PFCP message only after getting
the confirmation from the User Plane function of the Traffic Endpoint ID creation.
If the Control Plane function deletes a Traffic Endpoint, the User Plane function deletes all the PDRs that
refer to the Traffic Endpoint that was deleted by Control Plane function. For Evolved Packet Core (EPC), the
Remove Traffic Endpoint IE is used to delete a bearer for which multiple PDRs exist (with the same Traffic
Endpoint ID).
The Traffic Endpoints is used as a mechanism to identify the bearers uniquely for a given Sx session on the
User Plane. This is achieved with the help of Traffic Endpoint IDs that are associated with the PDRs of a
bearer.

PDI Optimization Changes on Control Plane

A new container, called Traffic Endpoint, is supported to carry the repeated PDI information of a given bearer.
Each Traffic Endpoint is associated with a Traffic Endpoint ID. This ID is unique for a given Sx Session.
A new IE, Create Traffic Endpoint IE, is supported as part of Sx Establishment Request.
Following are the new IEs supported as part of Sx Modification Request:
• Create Traffic Endpoint IE
• Update Traffic Endpoint IE
• Remove Traffic Endpoint IE

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
446
 Cisco Confidential - Limited Release
PDI Optimization
Create Traffic Endpoint IE

Create PDR supports a new IE, Traffic Endpoint ID, that identifies either the ingress or the egress Traffic
Endpoint of a bearer to which this PDR is associated.
A new IE, Created Traffic Endpoint IE, is supported as part of Sx Establishment Response and Sx Modification
Response message.

Create Traffic Endpoint IE

Following are the IEs in a Create Traffic Endpoint IE that are supported for a Pure-P call:
• Traffic Endpoint ID
• Local F-TEID
• Network instance
• UE IP address

Following are the IEs in a Create Traffic Endpoint IE that are supported for a Pure-S call:
• Traffic Endpoint ID
• Local F-TEID

NOTE: The Network instance and UE IP address IEs are currently not supported for a Pure-S call.
For a Collapsed call, Sxa Traffic Endpoints has IEs that are relevant to S-GW and Sxb Traffic Endpoints has
IEs that are relevant to P-GW.
In addition to the 3GPP standards defined IEs, a private IE called "Bearer Info IE", is added to the Create
Traffic Endpoint which includes:
• QCI of the bearer being created.
• ARP of the bearer being created.
• Charging ID of the bearer being created.

For a Pure-S call, there are two Traffic Endpoints that are created for each bearer of that PDN:
1. Create Traffic Endpoint for Ingress Traffic Endpoint, that is sent for the ingress F-TEID and referred by
ingress S-GW PDR of the bearer.
2. Create Traffic Endpoint for Egress Traffic Endpoint, that is sent for the egress F-TEID and referred by
egress S-GW PDR of the bearer.

For a Pure-S call, a bearer is uniquely identified on the User Plane that is based on Ingress and Egress Traffic
Endpoint IDs of the bearer. The Traffic Endpoints also store the QCI, ARP, and Charging ID of the bearer.
For a Pure-P call, only one Traffic Endpoint is created for each bearer of that PDN. Create Traffic Endpoint
for Ingress Traffic Endpoint, that is sent for ingress F-TEID and referred by ingress PDRs of the bearer. There
is no separate egress Traffic Endpoint that is created for a Pure-P call as no Tunnel Endpoint ID is allocated
on the P-GW egress. The same Traffic Endpoint is referred by both ingress and egress PDRs of a bearer. A
bearer is uniquely identified on the User Plane that is based on the Traffic Endpoint ID of the bearer. The
Traffic Endpoint also stores the QCI, ARP, and Charging ID of the bearer.
For a Collapsed call, there are two Traffic Endpoints that are created for the S-GW leg of the call for each
bearer. So, two Create Traffic Endpoints are sent for Ingress and Egress. The Sxa PDRs refer to these traffic
endpoints based on the direction (ingress or egress). Only one Traffic Endpoint is created for the P-GW leg

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
447
 Cisco Confidential - Limited Release
PDI Optimization
Created Traffic Endpoint IE

of the call for each bearer. The same Traffic Endpoint ID is referred by all Sxb PDRs of the bearer. For P-GW,
Create Traffic Endpoint is sent for the ingress. The Traffic Endpoint IDs of Sxa and Sxb PDRs identify the
bearer.

Created Traffic Endpoint IE

This IE is present in Sx Establishment/Sx Modification Response to inform Control Plane about the F-TEIDs
that were locally allocated by the User Planes for the various Traffic Endpoints that were created.
Following are the IEs in a Created Traffic Endpoint IE:
• Traffic Endpoint ID
• Local FTEID

The information that is received in Created Traffic Endpoint IE is processed by the Control Plane, and the
F-TEIDs that are allocated by the User Plane are stored in the Control Plane for ingress and egress accordingly.

Update Traffic Endpoint IE

This IE is present in Sx Modification Request to update the Traffic Endpoint information on the User Plane.
Following are the IEs in an Update Traffic Endpoint IE:
• Traffic Endpoint ID
• Local FTEID
• Network Instance
• UE IP address
• In addition to the 3GPP standards defined IEs, a private IE called "Bearer Info IE", is added to the Create
Traffic Endpoint which includes:
• QCI of the bearer
• ARP of the bearer
• Charging ID of the bearer

NOTE: Currently, the Update Traffic Endpoint IE supports only the update of Private IE extensions, such as
the Bearer Info IE. There are no use-cases wherein update of other information, such as Local FTEID, Network
Instance, UE IP address, is required.
When the QCI/ARP of a particular bearer EPS-Bearer Identity (EBI) is modified, then the modified QCI/ARP
along with the Charging ID is communicated to the User Plane with the help of Update Traffic Endpoint ID.
A given Traffic Endpoint ID can be updated only if it was successfully created on the User Plane.

Remove Traffic Endpoint IE

This IE is present in Sx Modification Request to remove a traffic endpoint. Traffic Endpoint ID is included
in the Remove Traffic Endpoint IE. A given Traffic Endpoint ID can be removed only if it is successfully
created on the User Plane.
For Pure-S, Pure-P, and Collapsed call, when a bearer is deleted on the Control Plane, the Traffic Endpoints
that are associated with the bearer are removed with Remove Traffic Endpoints. There is no explicit requirement
to send Remove PDRs and Remove FARs on that bearer.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
448
 Cisco Confidential - Limited Release
PDI Optimization
PDI Changes in Create PDR

On the User Plane, for a Pure-S call, Remove Traffic Endpoints deletes all the PDRs, FARs, and URRs of
that bearer. For Pure-P and Collapsed call, Remove Traffic Endpoints deletes all the PDRs, FARs, QERs, and
URRs of that bearer.

PDI Changes in Create PDR

When PDI Optimization is enabled for the PDN, then the Traffic Endpoint ID is set in the PDI field of all
PDRs of the bearers of the PDN. The PDI fields, such as F-TEID, PDN Instance, UE IP address, and so on,
are not supposed to be filled and so, these fields are validated in the User Plane and error messages are posted
in case of any validation failures. This is applicable for all interfaces, such as Sxa, Sxb, Sxab, N4, and Sxc.

PDI Optimization Changes on User Plane

Handling of Create Traffic Endpoint
When a Create Traffic Endpoint is received, the contents of the IE are validated for correctness. If validation
fails, then an error message is sent back to the Control Plane.
Validations fail in the following cases:
• Basic IE validation failures.
• Traffic Endpoint exists with this Traffic Endpoint ID.
• CH-bit not set in the F-TEID IE inside Traffic Endpoint.
• PDN Instance is not valid.
• UE IP address is not valid.

When a Create Traffic Endpoint is successfully processed, then a local F-TEID is allocated by the User Plane
and it is associated with the Traffic Endpoint. The Created Traffic Endpoint is sent back to Control Plane for
this Traffic Endpoint with the F-TEID information and Traffic Endpoint ID.
When a Create Traffic Endpoint list is processed on the User Plane in Sx Establishment Request, PDI
optimization is enabled for the lifetime of the Sx Session which cannot be changed midway.

Handling of Update Traffic Endpoint

When an Update Traffic Endpoint is received, the contents of the IE are validated for correctness. If validation
fails, then an error message is sent back to the Control Plane.
Validations fail in the following cases:
• Basic IE validation failures.
• Traffic Endpoint with its Traffic Endpoint ID does not exist.

NOTE: Currently, Update Traffic Endpoint updates only bearer information, such as QCI, ARP, and Charging
ID on the User Plane. Update is not supported for any other Traffic Endpoint parameters.

Handling of Remove Traffic Endpoint

When a Remove Traffic Endpoint is received, the contents of the IE are validated for correctness. If validation
fails, then an error message is sent back to the Control Plane.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
449
 Cisco Confidential - Limited Release
PDI Optimization
Handling of Create PDR

Validations fail in the following cases:

• Basic IE validation failures.
• Traffic Endpoint with its Traffic Endpoint ID does not exist.

When a Remove Traffic Endpoint is received, the PDRs associated with the Traffic Endpoint, FARs associated
with the PDR, QERs associated with the PDR, and URRs associated with PDR are also removed.
To remove a bearer, the Control Plane sends Remove Traffic Endpoints for the Traffic Endpoints that are
associated with the bearer resulting in the cleanup of the bearer-associated data on the User Plane.
The Control Plane does not explicitly send any Remove PDRs, Remove FARS, Remove QERS, or Remove
URRs for a bearer removal. However, if the Control Plane does send Remove PDRs, Remove FARS, Remove
QERS, or Remove URRs with Remove Traffic Endpoints, the message is accepted and successfully processed.

Handling of Create PDR

When Sx Session has the PDI Optimization enabled, the Traffic Endpoint ID is set for Create PDR. If not, an
error response is sent back to the Control Plane. The Create PDR validation fails in the following cases:
• Basic IE validation failures.
• Create PDR does not have Traffic Endpoint ID set in the PDI IE.
• Create PDR has valid F-TEID IE in PDI IE.
• Create PDR has valid PDN Instance IE in PDI IE.
• Create PDR has valid UE IP address IE in PDI IE.

For a Sx Session with PDI optimization disabled, the Create PDR is validated for various other fields. If
Traffic Endpoint ID is valid in PDI, then an error response is sent back to the Control Plane as Traffic Endpoint
ID should not be present for a Sx Session with the PDI optimization being disabled.

Session Recovery and ICSR

Control Plane
Session Recovery and ICSR are supported for the Traffic Endpoint IDs of all bearers of a PDN. The Traffic
Endpoint IDs are recovered for all bearers of a given PDN. This support is provided for Pure-S, Pure-P, and
Collapsed call. With this, PDI optimization enabled status for a PDN is also recovered. Full Checkpoint is
used for check-pointing and recovery of the Traffic Endpoints IDs of bearers.

User Plane
Session Recovery and ICSR are supported for the Traffic Endpoints on the User Plane for all bearers. All the
Traffic Endpoints, that are associated with a given Sx Session, are recovered. For a given Traffic Endpoint,
the associated PDR list is also recovered. For a given PDR, the associated Traffic Endpoint ID is recovered.

Standards Compliance
The PDI Optimization feature complies with the following standard: 3GPP TS 29.244 V15.5.0 (Interface
between the Control Plane and the User Plane Nodes).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
450
 Cisco Confidential - Limited Release
PDI Optimization
Limitations

Limitations
The PDI Optimization feature has the following limitations:
• The Network instance and UE IP address IEs are currently not supported for a Pure-S call.
• The Update Traffic Endpoint IE supports only the update of Private IE extensions, such as the Bearer
Info IE. Update of other information, such as Local F-TEID, Network Instance, UE IP address, are not
supported.
• The Update Traffic Endpoint updates only bearer information, such as QCI, ARP, and Charging ID on
the User Plane. Update is not supported for any other Traffic Endpoint parameters.

Configuring the PDI Optimization Feature

This section describes how to configure the PDI Optimization feature.

Enabling PDI Optimization

Use the following CLI commands to enable the feature.

configure
context context_name
sx-service service_name
[ no ] sx-protocol pdi-optimization
end
NOTES:
• no: Disables PDI optimization.
• By default, the CLI command is disabled.
• PDI Optimization is enabled or disabled at PDN level. PDI Optimization is enabled for each PDN based
on the configuration in sx-service. The PDN is PDI Optimization-enabled if the configuration is enabled
while processing Sx Establishment Request on the Control Plane.
• Configuration changes will not have any effect on the PDN. The configuration that is applied while
processing Sx Establishment Request will be maintained throughout the lifetime of the PDN. In a
multi-PDN call, each PDN has the configuration applied while PDN is set up.
• On the User Plane, there is no separate configuration to determine whether the PDN has PDI
Optimization-enabled. When Create Traffic Endpoint IE is received in Sx Establishment Request for a
Sx session, then the Sx session is considered to have PDI Optimization-enabled throughout the lifetime
of the session. This will not change dynamically midway, and validations are done accordingly. In case
of any validation failures, Error Response is sent back to the Control Plane.
• When there are multiple Create Traffic Endpoint IEs with the same Traffic Endpoint ID, the first Create
Traffic Endpoint IE is processed, and rest are ignored. The same behavior is applicable for Created Traffic
Endpoint IE, Update Traffic Endpoint IE, and Remove Traffic Endpoint IE.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
451
 Cisco Confidential - Limited Release
PDI Optimization
Verifying the PDI Optimization Feature Configuration

Verifying the PDI Optimization Feature Configuration

To verify if the PDI Optimization feature is enabled or disabled, use the show sx-service all CLI command.
The output of this show command has been enhanced to display the following:
• SX PDI Optimisation: [Enabled/Disabled]

PDI Optimization OAM Support

This section describes operations, administration, and maintenance information for this feature.

Show Command Support

The following show CLI commands are available in support of PDI Optimization feature.

show subscribers user-plane-only callid <call_id> pdr all

The output of this CLI command has been enhanced to display the following field: Associated Create Traffic
Endpoint-ID(s)

show subscribers user-plane-only callid <call_id> pdr full all

The output of this CLI command has been enhanced to display the following field:
• Create Traffic Endpoint-ID
• Bearer QOS
• QCI
• ARP
• Charging Id

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
452
 Cisco Confidential - Limited Release

CHAPTER 56
P-GW CDR in CUPS
• Revision History, on page 453
• Feature Description, on page 453
• User Location Information in P-GW CDR, on page 454

Revision History
Revision Details Release

Added the support for "User Location Information in P-GW CDR" in this release. 21.22

First introduced for custom24 P-GW GTPP dictionary. 21.14.a0 (5/9/2019)

Feature Description
In CUPS architecture, support is added for P-GW CDR generation for custom24 GTPP dictionary. The P-GW
CDR is generated for following procedure or scenario:
• Default Bearer:
• Volume/Time Limit
• PCRF initiated Rule Base change
• S-GW/PLMN change due to S1 Handover
• ULI/Time Zone change
• QoS change
• UE/Network initiated session deletion
• RAN-NAS cause code
• Maximum change condition trigger

• Dedicated Bearer:
• Volume/Time Limit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
453
 Cisco Confidential - Limited Release
P-GW CDR in CUPS
Limitations

• QoS change
• Handover Procedure
• ULI/Time Zone change
• PCRF rule base change
• UE/Network initiated Dedicated Bearer Deletion Procedure
• RAN-NAS cause code

Limitations
The aFRecordInformation is not supported in CUPS architecture.

User Location Information in P-GW CDR

The P-GW CDR contains the User Location Information (ULI) in the following two attribute fields:
• User Location Information (32)
• User Location Information (34-0-20)

As per the current behavior above two fields contain the “User Location information” in P-GW CDR. These
fields are getting updated only when ULI-change trigger is enabled. If ULI-change trigger is not configured,
the P-GW CDRs keeps the user location as it was reported in the initial CDR, even after the “Radio Access
Technology” gets changed.
To overcome this issue, this feature was introduced, that even if “ULI-change trigger” is disabled, Every CDR
contains the latest “User Location Information”. Functionality overview of this feature is as follows:
• This feature allows the P-GW CDRs to update User Location Information (32) and User Location
Information (34-0-20) attributes with the latest User Location Information provided by the MME and
S-GW.
• The implementation of the feature is through the different filler function specific to feature.
• To use this feature, customer/user requires to make the software changes at two places. First one is to
update the CDR custom/customer’s dictionary ULI fields with the newly implemented filler functions.
Current implementation is in the custom dictionary 38, as per requirement. Parallelly, the support for the
same dictionary need to be added under the MACRO:
“ACS_CHK_DICT_SUPPORT_FOR_LATEST_ULI”.

If the dictionary with the new filler functions are used, it packs the latest ULI in case of the following events:
Events to send/generate partial PGW-CDR for a subscriber:
• When the number of QoS changes or tariff time changes reaches the configured maximum number of
charging condition changes.
• Before this, service containers are added to the CDR for every change.
• Every x seconds configured using "interval x".

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
454
 Cisco Confidential - Limited Release
P-GW CDR in CUPS
User Location Information in P-GW CDR

• Every x octets configured using "volume x" (up/down/total).

• Command gtpp interim now active-charging egcdr.
• Transferring the context to a new S-GW/SGSN (serving Node Change).
• Changing the access type within the same P-GW (RAT Change).

Events to send or generate the final P-GW CDR for a subscriber:

• Detach Request received from UE
• Delete bearer context request received from S-GW.
• Manual subscriber clearing
• Abnormal Releases such as path failures.

Sample Configuration
Following are the sample configurations:
Customer dictionary: custom38
Customer running configuration:
gtpp group pgwhdd
gtpp attribute local-record-sequence-number
gtpp attribute node-id-suffix PGW11
no gtpp attribute twanuli
gtpp dictionary custom38
no gtpp trigger dcca
no gtpp trigger service-idle-out
no gtpp trigger serving-node-change-limit
no gtpp trigger inter-plmn-sgsn-change
no gtpp trigger qos-change
no gtpp trigger ms-timezone-change
gtpp trigger egcdr max-losdv
no gtpp trigger uli-change
gtpp egcdr lotdv-max-containers 1
gtpp egcdr losdv-max-containers 1
gtpp suppress-cdrs zero-volume-and-duration gcdrs egcdrs
gtpp egcdr service-data-flow threshold interval 43200
gtpp egcdr service-data-flow threshold volume total 104857600
gtpp storage-server mode local
gtpp storage-server local file purge-processed-files file-name-pattern

ACQ* purge-interval 2880

gtpp storage-server local file format custom3
gtpp storage-server local file rotation volume mb 30
gtpp storage-server local file rotation cdr-count 65000
gtpp storage-server local file rotation time-interval 600
gtpp storage-server local file name prefix PGW11_Laca
#exit.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
455
 Cisco Confidential - Limited Release
P-GW CDR in CUPS
User Location Information in P-GW CDR

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
456
 Cisco Confidential - Limited Release

CHAPTER 57
P-GW Restart Notification
• Revision History, on page 457
• Feature Description, on page 457

Revision History
Revision Details Release

First introduced. 21.14.0 (6/27/2019)

Feature Description
P-GW Restart notification (PRN) procedure is supported for UP communication over the Sx interface during
P-GW path failure. The P-GW Restart Notification procedure optimizes the amount of signaling involved on
the S11/S4 interface when a P-GW failure is detected.
PRN procedure is a standards-based procedure supported on S-GW to notify detection of P-GW failure to
MME/S4-SGSN.
P-GW failure detection will be done at S-GW when it detects that the P-GW has restarted (based on restart
counter received from the restarted P-GW) or when it detects that P-GW has failed but not restarted (based
on path failure detection).
When an S-GW detects that a peer P-GW has restarted, it locally deletes all PDN connection and bearer
contexts associated with the failed P-GW and notifies the MME through P-GW Restart Notification.
The S-GW, in the echo request/response on S11/S4 interface, indicates that the P-GW Restart Notification
procedure is supported.
P-GW Restart Notification Procedure is an optional procedure and is invoked only if both the peers,
MME/S4-SGSN and S-GW, support it.
In the absence of this procedure, S-GW will initiate the Delete procedure to clean up all the PDNs anchored
at that failed P-GW, which can lead to flooding of GTP messages on S11/S4 if there are multiple PDNs using
that S-GW and P-GW.
The following figure illustrates the PRN flow during a path failure.
In CUPS, when a path failure is detected:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
457
 Cisco Confidential - Limited Release
P-GW Restart Notification
Feature Description

IMAGE HERE
• On detecting S5 pathfailure S-GW initiates PRN processing if S-GW and MME supports the PRN feature.
• For a path failed session, if S-GW has not sent a PRN message to MME then it will send PRN message
once per MME.
• For path failed session, the S-GW CP sends a Sx Modify with FAR Action = DROP.
• On receiving Sx Modify Response, the S-GW CP sends Sx Delete Request to UP.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
458
 Cisco Confidential - Limited Release

CHAPTER 58
Post Processing Interaction for DCCA
• Feature Description, on page 459

Feature Description
The following diagram explains about the packet processing.
Figure 26: Post Processing Interaction for DCCA

Normal Rule Matching

In this phase, A comparison happens between the incoming packet against the configured rules in the box.
This rule matching process is nothing but categorizing the packet. Use the following CLIs for the Rule Matching
configuration in the box.
action priority <priority-number> ruledef <ruledef-name>
charging-action <charging-action>

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
459
 Cisco Confidential - Limited Release
Post Processing Interaction for DCCA
Application Processing

Based on priority order, the Rule Matching happens against the packet. The first rule that matches categorizes
the packet.
The corresponding charging-action applies to the packet. If the charging-action configuration contains “cca
charging credit”, then it triggers the online charging, for which the packet moves to the DCCA application.

Application Processing
Once the packet reaches the DCCA Application, it checks the quota for the packet (rating-group/content-id)
and makes the necessary processing. When there are no more credits for that rating-group, the
Final-Unit-Actions takes place on the packet. If no-credit is present in that rating-group, DCCA can also
blacklist the rating-group. When the application is blacklisting, the packet gets marked for Discard/Drop. The
packet is in the disposition-action to inform the ACS mgr. If the quota is present, the packet goes for forwarding.
The DCCA application can alternatively populate the post processing rules/filter list and mark the packet for
postprocessing. The postprocessing happens when the OCS has requested for applying the filter-ids or
filter-rules along with the Final-Unit-Indication AVPs. Once the DCCA application processing completes on
the packet, it goes back to the ACS mgr.

Post Processing
When the packet returns from the application, the ACS MGR, sees the disposition action value set by the
DCCA Application. If it’s marked for discard, it gets discarded.
• Application Requested Post-Processing: If the disposition-action applies for PP_RESTRICTION_RULE
or PP_FILTER_ID, it tries to get the corresponding restrict-rules-list or restrict-filter-id-list for the
content-id/rating-group. It applies the postprocessing. The packet doesn’t attempt for the
below-post-processing (General Post-Processing).
• ACS_CONTROL_PP_RESTRICTION_RULE: This disposition action applies, when the DCCA
activates Restriction-Filter-Rules sent by OCS, inside the Final-Unit-Indication Grouped-AVP, as
per RFC 4006. The Restriction-Filter-Rules are applicable in “restriction_list”, inside the
“fui_restrict_access”.
• ACS_CONTROL_PP_FILTER_ID: This disposition action applies, when the DCCA activates the
Filter-Ids, the OCS inside the Final-Unit-Indication grouped-AVP, as per RFC4006. The Filter-Ids
are nothing but the rule def names, and are applicable in “filter_id_list”, inside the
“fui_restrict_access”
DCCA Application can set both the disposition actions. Disposition-action is nothing but a bitmask.
These postprocessing restrict rules or postprocessing filter ids, that came from OCS and
enabled/activated by DCCA Application. This rule is rating-group specific rules. The rule-matches
happen in the order in which the OCS sends.
For each acs_sub_sess, there’s a list of “dcca_mscc_fui_restrict_access_t”, indexed on “service_id
& rating_group”. For each of this combination, the preceding type structure exists. This
“dcca_mscc_fui_restrict_access_t” structure contains the “filter_id_list” & “fui_restrict_access”
lists. This structure gets empty by default. The DCCA application can fill it when it activates the
corresponding post processing filtering for that service-id + rating-group.

• General Post Processing: If it’s forward, the post processing starts. During the post processing, the packet
gets matched against the configured post processing rules in the boxer.
Configure the post processing rules in boxer using the following CLIs:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
460
 Cisco Confidential - Limited Release
Post Processing Interaction for DCCA
Limit Reached Post Processing

Post processing priority <priority-number> ruledef <ruledef-name>

charging-action <charging-action-name>
These post processing rules get matched against the packet in the order of the priority-number.

Limit Reached Post Processing

In addition to the preceding two disposition action values, there’s one more value for limit-reached scenarios,
it’s ACS_CONTROL_PP_LIMIT_REACHED. Here the limit-reached indicates that the user quota-limit is
over. When the user quota is over, the packets get dropped by default, by application, and no post processing
applies. The feature is to add control on this limit-reached scenario, where post processing configuration
happens, even for this quota exhausted scenario.
A configurable option is available for enabling the post processing for limit-reached/quota-exhausted packets.
Use the following CLI for this configuration:
configure
active-charging service service_name
rulebase rulebase_name
post-processing policy { always | not-for-dynamic-discard }
end
The option “not-for-dynamic-discard” is the default option. This option indicates that the post processing
doesn’t apply for the limit-reached/quota-exhausted scenarios.
In case of the “post processing policy always” CLI, the post processing rules applies for the
limit-reached/quota-exhausted scenarios. The “ACS_CONTROL_PP_LIMIT_REACHED” value in the
disposition action is to communicate about this behavior. If there are post processing priority-based rules, it
checks for any redirection rules, else discards the packets by default. No other post processing actions like
forward, next-hop, X-header-insertion applies on these limit-reached packets.

Configuring Post Processing

The post processing rule def with the limit-reached case have “cca qutoa-state = limit-reached” configured,
along with the “rule-application post processing” option. This configuration is to indicate that this rule def is
for the limit-reached scenario.
ruledef http_low
http any-match = TRUE
cca quota-state = limit-reached
rule-application postprocessing
#exit

The corresponding charging-action has the “flow action redirect “configuration. Any other flow action values
are invalid for the limit-reached scenario.
charging-action redirect
flow action redirect-url http://webpages/index.html
#exit

Configure the post processing priority rules in the rule base in such a way that the limit reached post processing
rules is of the high priority. So that the packets get matched first against the limit-reached rule def.
rulebase base1
....................................
post processing priority 1 ruledef http_low charging-action redirect
#exit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
461
 Cisco Confidential - Limited Release
Post Processing Interaction for DCCA
Configuring Post Processing

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
462
 Cisco Confidential - Limited Release

CHAPTER 59
Priority Recovery Support for VoLTE Calls
• Feature Summary and Revision History, on page 463
• Feature Description, on page 463
• How It Works, on page 463
• Call Flows, on page 465
• Configuration, on page 466
• Monitoring and Troubleshooting, on page 467
• Show Commands and Outputs, on page 467

Feature Summary and Revision History

Revision History

Table 29: Revision History

Revision Details Release

First introduced 21.20.3

Feature Description
This feature helps to priorities the active and nonactive VoLTE calls over the normal calls. The priority is for
the recovery of calls due to the failure of the User Plane.

How It Works
There are two types of sessions in the User Plane:
• Normal Session
• Prioritized session

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
463
 Cisco Confidential - Limited Release
Priority Recovery Support for VoLTE Calls
How It Works

Prioritized session - The MP (message priority) bit set in PFCP header received from the Control Plane during
the Sx Session establishment/modification request. The prioritized sessions take precedence in case of recovery.
Normal calls recover only after the completion of the recovery of the prioritized calls.
The Control Plane sets the message priority (upper nibble of the 16th octet) in the PFCP header along with
the MP (second bit of the first Octet). Currently for EMPS calls, Message Priority is 1. Similarly, message
priority is 2 for VoLTE active calls and Message priority is 3 for VoLTE nonactive calls. Following figure
describes the message priority in PFCP header format for the various calls.

Bits
Octets 8 7 6 5 4 3 2 1
1 Version Spare Spare Spare MP = S=1
1
2 Message Type
3 Message Length (1st Octet)
4 Message Length (2nd Octet)
5 Session Endpoint Identifier (1st Octet)
6 Session Endpoint Identifier (2nd Octet)
7 Session Endpoint Identifier (3rd Octet)
8 Session Endpoint Identifier (4th Octet)
9 Session Endpoint Identifier (5th Octet)
10 Session Endpoint Identifier (6th Octet)
11 Session Endpoint Identifier (7th Octet)
12 Session Endpoint Identifier (8th Octet)
13 Sequence Number (1st Octet)
14 Sequence Number (2nd Octet)
15 Sequence Number (3rd Octet)
16 Message Priority Spare
= 1 EMPS/EMERGENCY
= 2 for VoLTE active call
= 3 for VoLTE nonactive

On receipt of SX Session establish/modification request, the User Plane marks the session as prioritized
session. The priority is based on nonzero (EMPS=1, VoLTE Active=2, VoLTE nonactive =3) value of the
message priority filled in the PFCP header.
This feature supports the following aspects for the Priority Recovery of VoLTE calls.
On Control Plane: (P-GW, S-GW, SAE-GW, GGSN)
• VoLTE call configuration under APN
• Sets the MP priority Bit and Message Priority in the PFCP header of SX session establishment request

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
464
 Cisco Confidential - Limited Release
Priority Recovery Support for VoLTE Calls
Call Flows

• Sets MP priority Bit and Message Priority in the PFCP header of SX session modification request

On User Plane:
• Checks the Message Priority of the PFCP header for the earlier messages
• If the message priority is nonzero, mark the session as priority session.
• These prioritized sessions are recovered before the nonprioritized sessions after SR /ICSR.

Call Flows
The following call flows explain about the:
• Session Establishment Handling
• Session Modification Handling

Session Establishment Handling Call Flow

The following call flow explains about the Session Establishment.

Session Modification Handling Call Flow

The following call flow explains about the Session Modification.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
465
 Cisco Confidential - Limited Release
Priority Recovery Support for VoLTE Calls
Configuration

Configuration
Following are the configurations for the Pure-P/Collapsed calls and Pure-S calls.

Configuring Pure-P or Collapsed Calls

Following are the configurations to mark the calls as VoLTE in Control Plane for Pure-P/Collapsed calls.
configure
context ingress
apn vrf.com
qci1 ims-media
end

Configuring Pure-S Calls

Following are the configurations to mark the calls as VoLTE in Control Plane for Pure-S/Collapsed calls.
configure
apn profile apn_1
qci1 ims-media
configure
operator-policy name intershat
apn default-apn-profile apn_1
end
configure
lte-policy
subscriber-map map_name
precedence 1 match-criteria all operator-policy-name intershat
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
466
 Cisco Confidential - Limited Release
Priority Recovery Support for VoLTE Calls
Monitoring and Troubleshooting

configure
context ingress
sgw-service sa_sgw_service
associate subscriber-map map_name
end

Monitoring and Troubleshooting

This section provides information on CLI commands that are available for monitoring and troubleshooting
for priority recovery of VoLTE calls.

Show Commands and Outputs

This section provides information about show CLI commands that are available in support of priority recovery
of VoLTE calls in User Plane.

show session subsystem facility sessmgr instance 1 debug-info

AAA TCP Connect Succeeded with : 0 Retries
fetched_from_aaamgr : 1 pror_to_audit : 1

passed_audit : 1 calls_recovered : 1

calls_recovered_by_tmr : 1 calls_recovered_by_med : 0

priority_calls_recoverd_by_med : 0 non_priority_calls_ignored_by_med: 0

show session subsystem facility aaamgr instance 1 debug-info

1 Current recovery archives 1 Current valid recovery records
1 Current valid priority recovery records

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
467
 Cisco Confidential - Limited Release
Priority Recovery Support for VoLTE Calls
Show Commands and Outputs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
468
 Cisco Confidential - Limited Release

CHAPTER 60
QoS Group of Ruledefs Support
• Revision History, on page 469
• Feature Descriptions, on page 469
• How It Works , on page 469
• Monitoring and Troubleshooting, on page 472

Revision History
Table 30: Revision History

Revision Details Release

First introduced 21.19

Feature Descriptions
QoS Group of Ruledefs is also called as QGR or SGQ. This feature enables fair usage policing for the
subscriber.

How It Works
The following configuration primarily does Flow-Status and Bandwidth Limiting in hierarchical manner, first
doing at matched Charging-Action and then at QoS-Group Level.
conf
active-charging service acs
qos-group-of-ruledefs QGR1
add-group-of-ruledef group
add-ruledef http
#exit
rulebase cisco
action priority 2 ruledef http charging-action standard
action priority 5 ruledef catchall charging-action standard
route priority 1 ruledef http-rule analyzer http
end

QoS Group QGR1 received over PCRF.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
469
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Data Path Enforcement

qos-group-rule-install
qgr-name QGR2
qgr-mon-key 1
qgr-flow-status 3
qgr-precedence 1
qgr-eqos-information
qgr-eqos-mbr 1000 2000
qgr-eqos-mbr-burst-size 1000 2000
qgr-eqos-mbr-limit-conform-action 1 -1 1 -1
qgr-eqos-mbr-limit-exceed-action 2 7 2 8

Data Path Enforcement

1. Packet matches ruledef ‘http’.
2. QGR match is carried out to check if there is a QGR with the matched ruledef/group. Highest Priority
QGR is returned. The ruledef/group can be static or predefined.
3. If QGR matches, then Flow-Action Enforcement which is first done at Charging-Action Level and then
at QGR Level assuming Charging-Action has allowed the packet. If the packet is dropped, then QGR
Level Flow Action Enforcement is skipped.
4. If Flow-Action at QGR allows the packet, then QER Limiting is enforced on a packet. If it is dropped at
QGR, QER Limiting is skipped.
5. Likewise, QER Limiting is done stepwise, first at Charging-Action Level and then at the QGR subject to
packet is allowed at Charging-Action.

Static Configuration Push to UPlane

• Static configuration pushed from CP to UP via the PFD mechanism in similar to ECS elements
ruledef/charging-action/group-of-ruledefs.
• Show CLIs ‘show user-plane-service qos-group-of-ruledefs all/name’ displays the static configuration
on UPlane.

QGR Params Push to UPlane

QGR is pushed along with Session Establishment and Modification Request.
QGR Name and Precedence is sent in a private IE. Flow-action, bandwidth parameters, and monitoring-key
will create a new FAR, new QER, and new URR respectively.
Any changes to QGR dynamic parameters triggers an update to FAR/QER/URR.
This is sent in Session Establishment or Modification Request.
Private IE
Qos-Group-Of-Ruledef:
Name:
Operation: (0 – Add 1 - Modify 2 - Delete)
Precedence:
FAR ID:
URR ID:
QER ID:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
470
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Processing of QGR on UPlane

Table 31: FAR Format

FAR ID Unique ID

Extended Apply Action Private IE to include Flow-Action Allow as well

Discard, Uplink, Discard Downlink, Terminate Flow.

Table 32: QER Format

QER ID Unique ID

Maximum Bitrate MBR of QGR in Kbps:

UL MBR:
DL MBR:

Burst Size Private IE to include the Burst Size:

UL Burst:
DL Burst:

Conform Action Private IE to configure the conform action:

Uplink Action:
Uplink ToS:
Downlink Action:
Downlink ToS:

Exceed Action Private IE to configure the exceed action:

Uplink Action:
Uplink ToS:
Downlink Action:
Downlink ToS:

Display the FAR, PDR, QER, and URR in ‘show subscribers user-plane-only callid <> far|qer full all’.

Processing of QGR on UPlane

• On Receiving a IE ‘Qos-Group-Of-Ruledef', search for the QGR in static configuration. For each
ruledef/group-of-ruledef in QGR, look up for its corresponding PDR and update the FAR/QER list with
the received QGR FAR/URR/QER IDs.
• For each ruledef/group-of-ruledef PDR on UPlane, associate high priority QGR’s FAR-id, QER-id.
• Maintain QGR map at both Control and UPlane, it consists of QGR name, precedence, QER-ID, and
FAR-ID. Use QGR map for recovery and lookup whenever required.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
471
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
QGR Hit in Data Path

QGR Hit in Data Path

• For a packet matching rule PDR, search for the highest priority QGR FAR, and QER and enforce the
parameters.
• Enforce flow-status and flow-rate as expected.
• QGR matching for Offloaded Flows are handled.
• QGR hit statistics are incremented.

Limitations
The QoS Group of Ruledefs support feature has the following limitations:
• URR creation and enforcement is not supported.
• Inclusion of dynamic-rules in static QGR definition is not supported.
• Flow-Status Redirect and Kill Flow are not supported.
• QoS Group Conform action as Drop and Exceed action as ALLOW or MARK_DSCP are not supported.
• CP can communicate maximum 20 QGRs received over PCRF to UP.

Monitoring and Troubleshooting

This section provides information about CLI commands available for monitoring and troubleshooting the
feature.

Show Commands and Outputs

This section provides information about show commands and their outputs in support of this feature.

show subscribers user-plane-only full all

The output of this show command has been enhanced to include the following fields introduced in support of
this feature.
• Total QoS-Group Active
• QoS-Group Statistics
• QGR Name
• Pkts-Down
• Bytes-Down
• Pkts-Up
• Bytes-Up
• Hits

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
472
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Show Commands and Outputs

• Match-Bypassed
• FP-Down(Pkts/Bytes)
• FP-Up(Pkts/Bytes)

show user-plane-service qos-group-of-ruledefs all name

The output of this show command has been enhanced to include the following fields introduced in support of
this feature.
QGR-INFO-LIST
• Value
• Number of QGRs
• QGR INFO
• NAME
• PRECEDENCE
• OPERATION
• FAR ID
• QER ID

• QGR INFO
• NAME
• PRECEDENCE
• OPERATION
• FAR ID
• QER ID

show subscribers user-plane-only callid 00004e21 qos-group all

The output of this show command has been enhanced to include the following fields introduced in support of
this feature.
Callid: 00004e21
Interface Type: Sxb
QGR-Name: Priority: FAR-ID: QER-ID: URR-ID:
--------- --------- ------- ------- ------

Total Number of QGRs found:

show subscribers user-plane-only callid 00004e21 far full all

The output of this show command has been enhanced to include the following fields introduced in support of
this feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
473
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Show Commands and Outputs

• Associated with QGR

• Extended Apply Action

show subscribers user-plane-only callid 00004e21 qer full all

The output of this show command has been enhanced to include the following fields introduced in support of
this feature.
• UL Burst
• UL Conform Action
• UL DSCP Value

• UL Exceed Action
• UL DSCP Value

• DL Burst
• DL Conform Action
• DL DSCP Value

• DL Exceed Action
• DL DSCP Value

show subscribers user-plane-only callid 00004e21 qos-group statistics all name

This show command and its output is introduced to support of this feature.
• Flow-Status Statistics
• Total Uplink Packets
• Total Uplink Bytes
• Uplink Packets Redirected
• Uplink Bytes Redirected
• Uplink Packets Dropped
• Uplink Bytes Dropped
• Uplink Packets Term-Flow
• Uplink Bytess Term-Flow
• Total Downlink Packets
• Total Downlink Bytes
• Downlink Packets Redirected
• Downlink Bytes Redirected

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
474
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Show Commands and Outputs

• Downlink Packets Dropped

• Downlink Bytes Dropped
• Downlink Packets Term-Flow
• Downlink Bytes Term-Flow

• Bandwidth-Control Statistics
• Total Uplink Packets
• Total Uplink Bytes
• Uplink Packets QoS-Exceed
• Uplink Bytes QoS-Exceed
• Uplink Packets QoS-Conform
• Uplink Bytes QoS-Conform
• Uplink Packets Dropped
• Uplink Bytes Dropped
• Uplink Packets Marked
• Uplink Bytes Marked
• Total Downlink Packets
• Total Downlink Bytes
• Downlink Packets QoS-Exceed
• Downlink Bytes QoS-Exceed
• Downlink Packets QoS-Conform
• Downlink Bytes QoS-Conform
• Downlink Packets Dropped
• Downlink Bytes Dropped
• Downlink Packets Marked
• Downlink Bytes Marked

• Total qos-group-of-ruledefs matched

• Total subscribers matching specified criteria

show user-plane-service statistics qos-group sessmgr all

Sessmgr Instance
• Total Uplink Pkt
• Total Uplink Bytes

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
475
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Show Commands and Outputs

• Uplink FP Pkts
• Uplink FP Bytes
• Total Dnlink Pkts
• Total Dnlink Bytes
• Dnlink FP Pkts
• Dnlink FP Bytes

• Flow-Status Statistics
• Total Uplink Packets
• Total Uplink Bytes
• Uplink Packets Redirected
• Uplink Bytes Redirected
• Uplink Packets Dropped
• Uplink Bytes Dropped
• Uplink Packets Term-Flow
• Uplink Bytess Term-Flow
• Total Downlink Packets
• Total Downlink Bytes
• Downlink Packets Redirected
• Downlink Bytes Redirected
• Downlink Packets Dropped
• Downlink Bytes Dropped
• Downlink Packets Term-Flow
• Downlink Bytes Term-Flow

• Bandwidth-Control Statistics
• Total Uplink Packets
• Total Uplink Bytes
• Uplink Packets QoS-Exceed
• Uplink Bytes QoS-Exceed
• Uplink Packets QoS-Conform
• Uplink Bytes QoS-Conform
• Uplink Packets Dropped

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
476
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Show Commands and Outputs

• Uplink Bytes Dropped

• Uplink Packets Marked
• Uplink Bytes Marked
• Total Downlink Packets
• Total Downlink Bytes
• Downlink Packets QoS-Exceed
• Downlink Bytes QoS-Exceed
• Downlink Packets QoS-Conform
• Downlink Bytes QoS-Conform
• Downlink Packets Dropped
• Downlink Bytes Dropped
• Downlink Packets Marked
• Downlink Bytes Marked

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
477
 Cisco Confidential - Limited Release
QoS Group of Ruledefs Support
Show Commands and Outputs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
478
 Cisco Confidential - Limited Release

CHAPTER 61
Rate Limiting Function (RLF)
This chapter contains the following topics:
• Revision History, on page 479
• Feature Description, on page 479

Revision History
Revision Details Release

First introduced. 21.10 (31/7/2018)

Feature Description
The RLF feature implements a generic framework that can be used by multiple interfaces and products for
rate-limiting/throttling outgoing messages like Diameter messages on Gx, Gy interface towards PCRF.

Important The working of RLF feature, including the CLI commands, in the CUPS architecture is similar to how it works
in the non-CUPS environment.

When applications send messages to peers at a high rate (for example, when a large number of sessions goes
down at the same time), accounting stop messages for all the sessions are generated at the same time) the peer
may not be able to handle the messages at such high rates. To overcome this situation, the Rate Limiting
Function (RLF) framework is developed so that the application sends messages at an optimal rate such that
peer is capable of receiving all the messages and does not enter an overload condition.
This feature can be enabled using the rlf-template CLI command in the Global Configuration mode. The
users can define the rate limiting configurations within this template. For more information on the command,
see the Command Line Interface Reference.

Important RLF template cannot be deleted if it is bound to any application (peers/endpoints).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
479
 Cisco Confidential - Limited Release
Rate Limiting Function (RLF)
Feature Description

When RLF feature is enabled, all the messages from the application are pushed to the RLF module for throttling
and rate control, and depending on the message-rate configured the RLF module sends the messages to the
peer. Once the rate or a threshold value is reached, the RLF module notifies the application to slow down or
stop sending messages. RLF module also notifies the application when it is capable of accepting more messages
to be sent to the peer. RLF module typically uses a Token Bucket Algorithm to achieve rate limiting.
Currently in the deployment of the Diameter applications (Gx, Gy, and so on), many operators make use of
max-outstanding number CLI command as a means of achieving some rate-limiting on the outgoing control
traffic. With RLF in place, this is no longer required since RLF takes care of rate-limiting in all cases. If both
RLF and max-outstanding is used, there might be undesirable results.

Important If RLF is being used with a diameter endpoint, then set the max-outstanding value of the peer to be 255.

To use the template, Diameter or any other applications must be associated with the template. The RLF
provides only the framework to perform the rate limiting at the configured Transactions Per Second (TPS).
The applications (like Diameter) should perform the configuration specific to each application.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
480
 Cisco Confidential - Limited Release

CHAPTER 62
S2a Interface Support
• Revision History, on page 481
• Feature Description, on page 481

Revision History
Table 33: Revision History

Revision Details Release

First introduced. 21.14.x

Feature Description
This reference point supports the bearer interface by providing signaling and mobility support between a
trusted non-3GPP access point (Trusted WiFi Gateway (TWAN)/Converged Access Gateway (CGW)) and
PDN Gateway (P-GW). It is a GTP based interface support that allows the connectivity to the trusted non-3GPP
IP access points. The S2a interface uses IPv4 and IPv6 for both control and data.

Supported Protocols
• Transport Layer: UDP, TCP
• Tunneling: GTP IPv6
• Network Layer: IPv4, IPv6
• Data Link Layer: ARP
• Physical Layer: Ethernet

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
481
 Cisco Confidential - Limited Release
S2a Interface Support
Feature Description

Figure 27: Protocols Supported on the S2a Interface

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
482
 Cisco Confidential - Limited Release

CHAPTER 63
S2b Interface Support
• Feature Description, on page 483

Feature Description
In CUPS architecture, support is added for S2b interface where untrusted Wi-Fi calls from ePDG connects
to SAEGW (Pure-P).
Currently, support for following procedures are available:
• Support procedures for session establishment:
• GTP based S2b for roaming, non-roaming and LBO (3GPP TS 23.402 [4] clause 7.2.4).
• Emergency services over GTP based S2b (3GPP TS 23.402 [4] clause 7.2.5).
• UE-initiated connectivity to additional PDN from Un-trusted Non-3GPP IP Access with GTP (3GPP
TS 23.402 [4] clause 7.6.3).

• Support procedures for session release:

• UE/ePDG-initiated detach procedure with GTP on S2b (TS 23.402 [4] clause 7.4.3.1).
• HSS/AAA-initiated detach procedure with GTP on S2b (TS 23.402 [4] clause 7.4.4.1).

• Support procedure for bearer deactivation:

• P-GW Initiated Bearer Deactivation with GTP on S2b (TS 23.402 [4] clause 7.9.2).

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
483
 Cisco Confidential - Limited Release
S2b Interface Support
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
484
 Cisco Confidential - Limited Release

CHAPTER 64
S-GW CDR in CUPS
• Revision History, on page 485
• Feature Description, on page 485

Revision History
Revision Details Release

First introduced. 21.14.B0 (4/16/2019)

This feature is not fully qualified in this release.

Feature Description
CDR generation is supported for S-GW in the Cisco UPC CUPS architecture.
CDRs in CUPS is generated to collect charging information for UE bearers in S-GW. On receiving a charging
trigger, the Control Plane node of CUPS pulls the information from the corresponding user plane nodes and
the collected volume counts are added to the S-GW CDR.
S-GW CDR is supported for both default and dedicated bearer.

Note Currently, S-GW CDR is supported in custom24 dictionary.

Charging data is collected based on the following triggers:

• Access-side triggers:
• ULI Change
• RAT Change
• Management intervention (Interim CDRs are not supported)
• Normal/Abnormal call release

• Network-side triggers:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
485
 Cisco Confidential - Limited Release
S-GW CDR in CUPS
Feature Description

• QCI Change
• APN AMBR Change

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
486
 Cisco Confidential - Limited Release

CHAPTER 65
S-GW New Call Rejection
• Feature Description, on page 487
• How It Works, on page 487
• Configuring S-GW New Call Rejection, on page 488
• Monitoring and Troubleshooting, on page 489

Feature Description
This CLI-controlled feature allows to reject Pure-S calls based on subscriber type (Roamer, Homer, Visitor),
and/or APN.

Note This feature is applicable only when CUPS is enabled.

How It Works
When a new call arrives at S-GW, and if the feature CLI is enabled with which the APN of the call matches
to the one configured through the CLI, the call is rejected. This feature works by identification of the type of
subscribers—homer, visitor, or roamer. This identification is done in the following way:
• If the PLMN ID of S-GW is same as that of PGW and International Mobile Subscriber Identity (IMSI),
the subscriber is identified as homer.
• If the PLMN ID of S-GW differs from PLMN ID of PGW irrespective of IMSI, the subscriber is identified
as roamer. For example, if MS-1 is subscribed to PLMN1 and is connected to an SGW in PLMN2, then
from PLMN2, MS-1 initiates a session with the PGW in PLMN1. In this scenario, MS-1 is roamer.
• Subscribers whose IMSI contains a foreign PLMN ID are identified as visitors.

The S-GW rejects all sessions of APNs that are configured for home, visitor, or roamer subscriber. Initial
attach CS Request and UE requested additional PDN connection CS requests for Pure-S calls are also considered
for rejection. The CS request is rejected with GTPV2 cause No Resource Available. The expected behaviour
is that the MME reattempts attach based on this cause code, and blacklist this S-GW based on its blacklist
algorithm implementation.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
487
 Cisco Confidential - Limited Release
S-GW New Call Rejection
Limitations

A configuration for list of APNs (maximum 10), which needs to be rejected by S-GW for homer and roamer
subscribers, is required.
In case of SAEGW deployment, only Pure-S calls are rejected. If SAEGW receives CS request for collapsed
call, then this call is not rejected even if corresponding APN is configured in the reject list.
Emergency or eMPS calls are not rejected, despite IMS APN being configured for new call reject, when:
• The S-GW receives CS request with IMS APN and unauthenticated imsi flag set.
• The S-GW receives CS request with IMS APN and eARP value is configured as eMPS eARP in S-GW
service.

Note In the CS Request, eARP is received by S-GW, which is not configured as eMPS eARP. While in CS Response,
the S-GW can receive new authorized eARP which can mark sessions as eMPS session. However, if the
feature is enabled in case of CS Response, sessions are rejected while handling CS Request only.

Limitations
When Pure S call is rejected through new call reject policy, the rejection statistics is collected under New Call
Policy Rejection Stats section of the show saegw-service statistics all function sgw CLI command. Other
SGW-related statistics for the rejected call are not collected.

Configuring S-GW New Call Rejection

This section provides information on configuration commands to enable and disable support for S-GW to
reject new calls.

Enabling New Call Rejection

Use the following configuration commands to reject calls at S-GW for roamer, home, visitor subscribers, and
APN subscribers.
configure
contextcontext_name
sgw-service sgw-service_name
[ default | no ] newcall reject { roamer | home [ apn apn_name ]
| visitor [ apn apn_name }
end
NOTES:
• default: Resets the command to it its default setting - Disabled.
• no: Disables the rejection of all calls for the specified subscriber.
• newcall: Configures a new call for the configured S-GW service.
• reject: Configures newcall reject-policy for the configured S-GW service home, visitor, or roamer
subscriber.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
488
 Cisco Confidential - Limited Release
S-GW New Call Rejection
Monitoring and Troubleshooting

• roamer: Configures newcall reject-policy for the configured S-GW service for roamer subscriber.
• home: Configure newcall reject-policy for the configured S-GW service for home subscriber.
• visitor: Configures newcall reject-policy for the configured S-GW service for visitor subscriber.
• apn-name apn_name: Configures the APN name (for maximum of 10 APN profiles) to reject call for
the configured S-GW service for home or visitor subscriber.

Monitoring and Troubleshooting

This section provides information regarding commands available to monitor and troubleshoot the new call
and APN session rejection at S-GW.

Show Command(s) and/or Outputs

This section provides information about show commands and the fields that are introduced in support of new
call and APN session rejection at S-GW.

show saegw-service statistics all function sgw

The output of this show command has been modified to display apn-profiles that are configured in sgw-service
for new call rejection. Following fields are introduced:
• New Call Policy Rejection Stats
• New Calls
• Visiting Subscriber
• Home Subscriber
• Roaming Subscriber

show sgw-service name

The output of this show command has been modified to display apn-profiles that are configured in sgw-service
for new call rejection. Following fields have been introduced:
• SGW Reject Calls Visitor Subs
• SGW Reject Calls Roamer Subs
• SGW Reject Calls Home Subs

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
489
 Cisco Confidential - Limited Release
S-GW New Call Rejection
show sgw-service name

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
490
 Cisco Confidential - Limited Release

CHAPTER 66
S-GW Session Idle Timeout
• Revision History, on page 491
• Feature Description, on page 491
• Configuring Session Idle Timeout, on page 492

Revision History
Revision Details Release

First introduced. 21.17

Feature Description
This chapter describes the Idle Timeout Handling feature for S-GW sessions. On the ASR5500 platform,
subscriber session is represented by call-line. The S-GW product call-line interfaces to its peers through
MME/S4-SGSN on S11/S4 and P-GW on S5/S8. In some scenarios, peer sessions are deleted by respective
peers, S-GW does not receive or miss deletion messages, and as a result S-GW session remains idle. Such
idle or stale sessions are counted towards valid call-lines in system for effectively consuming resources and
causing capacity reduction. In such cases, S-GW triggers to get the new subscriber session, which results in
the removal of old session for same subscriber. The Idle Timeout Handling support enables the identification
of such sessions and initiates deletion to release the resources.
The following points describes the idle timeout handling for S-GW sessions:
• The subscriber session is idle when there is no data traffic activity for the subscriber. The session manager
keeps track of the call-line state, when no data traffic is recorded for call-line, such sessions are moved
to idle state.
• Session which is idle for defined timeframe referred as idle timeout is considered for idle timeout handling.
In idle timeout session, S-GW initiates the deletion of session towards its peers.
• Idle timeout is configured in seconds depending on the network requirements. The timeout range is
1-4294967295 seconds.
• The idle timeout configuration is applicable on S-GW service level for enabling the idle timeout handling
for set of subscribers handled by that service.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
491
 Cisco Confidential - Limited Release
S-GW Session Idle Timeout
Configuring Session Idle Timeout

Configuring Session Idle Timeout

The session idle timer for S-GW sessions is configurable from S-GW service.
To configure Session Idle Timeout for S-GW, use the following configuration:

configure
context context_name
sgw-service service_name
[ no | default] timeout idle timeout_duration
end
NOTES:
• timeout idle timeout_duration: Specifies the maximum duration a session can remain idle for, in seconds,
before the system automatically terminates the session. timeout_duration must be an integer in the range
of 1-4294967295. 0 disables the feature. By default, it is disabled for the S-GW service.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
492
 Cisco Confidential - Limited Release

CHAPTER 67
SAEGW Idle Buffering with DDN Delay and DDN
Throttling
• Revision History, on page 493
• Feature Description, on page 494
• How It Works, on page 494
• SAEGW Idle Buffering with DDN Delay and DDN Throttling Support Configuration, on page 503

Revision History
Revision Details Release

With this release, Handling added for some of the collisions of DDN message 21.15.1 (09/13/2019)
with other messages.

With this release, the following functionalities are supported: 21.14 (06/27/2019)
• Buffering support for Pure-S calls along with DDN throttling, DDN Delay
and High priority DDN in Pure-S.
• Session Recovery and ICSR is supported for DDNs

With this release, the following functionalities are supported: 21.12 (01/29/2019)
• DDN Delay with Delay Timer Support.
• DDN Throttling.
• No User Connect Timer Support.

With this release, following functionalities are supported: 21.12 (12/21/2018)

• DDN Delay.
• High priority DDN (only for default bearer).
• DDN failure scenarios.

First introduced. 21.10 (8/14/2018)

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
493
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
Feature Description

Feature Description
The Downlink Data Notification (DDN) messages with support for DDN Delay and DDN Throttling, and
buffering in SAEGW, when UE is in Idle State, is supported in CUPS architecture.

How It Works
This section provides an overview of how this feature works.
• Buffering is supported at SAEGW-U.
• Support of buffering starts when UE moves to IDLE state due to Release Access Bearer.
• ACTIVE to IDLE transition:
• When the UE moves to ECM-IDLE state, since the SAEGW supports buffering capability and
decides to activate buffering in SAEGW-U for the session, the SAEGW-C informs the SAEGW-U
through an Sx session modification.
• After the buffering starts, when the first downlink packet arrives on any bearer, the SAEGW-U
informs the SAEGW-C. The SAEGW-U sends an Sx reporting message to the SAEGW-C, unless
specified otherwise, and identifies the S5/S8 bearer on which the downlink packet is received.
• On receiving the reporting message, the SAEGW-C decides whether to send a DDN message to the
MME, as defined in 3GPP TS 23.401 [2]. The DDN notification is sent with the Sx-Usage-Report.

• IDLE to ACTIVE transition:

• At the UE transition to ECM-CONNECTED state, the SAEGW-C updates the SAEGW-U through
Sxa interface with the F-TEIDu of the eNodeB/RNC/SGSN. The buffered data packets, if any, are
then forwarded to the eNodeB/RNC/SGSN by the SAEGW-U.

• If the Apply Action is BUFFER, and SGW-U recovers, the SGW-U initiates Sx Report (with DLDR
Report Type) on arrival of the downlink data packet.
• In SGW-U, a timer is implemented that starts after each Sx Report (with DLDR report Type) is sent. If
the Apply Action is not changed then on timer expiry, Sx Report (with DLDR Report Type) gets initiated
again.
• ARP of the bearer is included in the DDN message.
• In a multi-PDN session, if the DDN is initiated for one PDN and then data is received on another PDN,
wherein the bearer has higher priority, then the DDN is initiated again with the higher priority ARP
value.

Downlink Data Notification – Delay (DDN-D) Support

Under certain conditions, when UE triggers a service request, uplink and downlink data is triggered and is
received at the SGW-C even before the Modify Bearer Request (MBR) is received causing unnecessary
Downlink Packet Notification messages sent that increases the load in MME.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
494
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
DDN Throttling Support

In such cases, the MME monitors the rate at which these events occur. If the rate becomes significant (as
configured by the operator) and the MME's load exceeds an operator configured value, the MME indicates
"Delay Downlink Packet Notification Request" with parameter D to the Serving Gateway, where D is the
requested delay given as an integer with multiples of 50 milliseconds, or zero. The S-GW then uses this delay
in between receiving downlink data and sending the Downlink Data Notification message.
The Downlink Data Notifications are supported for both Collapsed and Pure-S calls.
Due to the distributed nature of the system, sessions from a particular MME are offloaded on different session
managers. Therefore, all session managers are notified when a session is offloaded. Also, the functionality is
designed to not allow all session managers to message the DEMUX manager.
• In DDN Delay feature, DDN delay timer support is at Control Plane.
• When first data packet arrives, Sx Report message is initiated but DDN message is initiated from Control
Plane after the expiry of Delay timer.
• DDN Delay feature is a peer level feature and so, it is applied for all the session on that peer from where
the DDN Delay value is received.
• In case a previous delay value was received from a peer and it is absent in the current message, the delay
value will be considered as 0.

Session Recovery and ICSR is supported for DDNs.

DDN Throttling Support

Too many DDN requests towards MME from SGW-C could lead to processing overload at MME. To reduce
this load, MME dynamically requests SGW-C to reduce a certain percentage of DDN messages sent towards
it for a given period time.
For DDN throttling, S-GW is required to drop a given percentage of DDNs over a given period of time. S-GW
implements this functionality using a probabilistic algorithm at each session manager.
Whereas, the conventional implementation of DDN throttling requires each session manager to share its list
of pending DDNs for low priority bearers with a central entity that would then calculate the net load of pending
DDNs and then decide how many DDNs each session manager would have to drop. This implementation
would require buffering of DDN messages at session manager. Also, due to distributed processing nature of
software subsystem in chassis, it would require considerable amount of messaging between the session
managers and the central entity (demuxmgr in case of Boxer) at regular intervals.
Implementing a probabilistic algorithm removes the need for buffering at session manager and also messaging
with demuxmgr. Accuracy of probabilistic algorithm increase with increasing low ARP priority paging load
at session manager. Even with lower paging load, accuracy would be fairly close to the throttling factor
provided.
For non-release 10 compliant MME, SGW_C provides option to enable throttling through the CLI.
Threshold ARP values for low priority bearer must be configured through S-GW Service Configuration. For
example, if configured ARP value is 9, any bearer with ARP > 9 is considered low priority bearer. DDN
throttling is enabled through this configuration. If DDN throttling is enabled through SGW service configuration,
each DDN message towards MME would contain the ARP IE.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
495
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
No User Connect Timer Support

No User Connect Timer Support

• Timer is introduced when a Modify Bearer Request is not received after positive Downlink Data
Notification acknowledgment.
• It is initiated at SGW-C when DDN acknowledgment is received.
• On arrival of Modify Bearer Request, SGW-C stops this timer.
• On timer expiry SGW-C informs SGW-U to drop buffered packets.

DDN Call Flows

DDN Success Scenario

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
496
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
DDN Failure Scenario

1. MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the
bearers for that UE.
2. On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR
with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
3. SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
4. SGW-C sends Release Access Bearer response to MME.
5. First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink
Data Report) towards SGW-C.
6. On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request
message towards MME.
7. SGW-C sends Sx Report Response message towards SGW-U.
8. If MME is able to send a paging request towards UE, it sets the cause as “Request Accepted” in Downlink
Data Notification Acknowledgment Message and sends it to SGW-C.
9. On successful paging, MME sends a Modify Bearer request to the S-GW with eNodeB TEIDs that sets
up the S1-U connection at the SGW.
10. SGW-C sends Sx Modification request with updated FAR for new TEID information to SGW-U. SGW-U
can now forward all the buffered data to UE through eNodeB.
11. SGW-U sends Sx Modification response to SGW-C.

DDN Failure Scenario

1. MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the
bearers for that UE.
2. On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR
with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
3. SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
4. SGW-C sends Release Access Bearer response to MME.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
497
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
No User Connect Timer Support

5. First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink
Data Report) towards SGW-C.
6. On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request
message towards MME.
7. SGW-C sends Sx Report Response message towards SGW-U.
8. If MME is not able to page UE then it can reject Downlink Data Notification Request with relevant
cause.
OR
If MME accepts Downlink Data Notification Request. But later sends Downlink Data Notification
Failure indication in order to indicate SGW-C that the UE did not respond to paging.
9. SGW-C received DDN failure and hence to stop sending next DDN immediately , SGW-C starts DDN
Failure Timer.SGW-C sends Sx Modification Request with DROBU flag to discard buffered packets
and Apply Action as DROP to drop subsequent packets.
10. SGW-U sends Sx Modification Response to SGW-C.
11. On DDN Failure Timer Expiry SGW-C initiates Sx Modification with Apply Action as BUFFER in
order to start buffering again.

Further steps are continued from Step 3 in theDDN Success Scenario, on page 496 call flow.

No User Connect Timer Support

1. MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the
bearers for that UE.
2. On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR
with Apply Action as BUFFER in Sx Modification Request for all the PDNs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
498
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
No User Connect Timer Support

3. SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
4. SGW-C sends Release Access Bearer response to MME.
5. First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink
Data Report) towards SGW-C.
6. On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request
message towards MME.
7. SGW-C sends Sx Report Response message towards SGW-U.
8. Downlink Data Notification Acknowledgment is received from MME.SGW-C starts no-user-connect
timer.
9. If the Modify Bearer request with eNodeB TEID information is not received and no-user-connect timer
expires, SGW-C sends Downlink Data Notification again.
10. Downlink Data Notification Acknowledgment is received from MME. SGW-C initiates the
no-user-connect timer again.
11. SGW-C initiates Sx Session Modification request towards SGW-U with DROBU flag set in the message.
On receiving this flag SGW-U drops the buffered data. New data will be buffered, and the subsequent
first packet initiates a Sx Report message for initiating Downlink Data Notification message.
12. SGW-U sends Sx Modification Response.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
499
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
DDN Delay Timer

DDN Delay Timer

1. MME sends Release Access Bearer request to SGW-C to release downlink remote TEIDs of all the
bearers for that UE.
2. On arrival of Release Access Bearer request, SGW-C informs the same to SGW-U by updating FAR
with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
3. SGW-U send Sx Modification response after applying Buffering in SGW-U for corresponding PDN.
4. SGW-C sends Release Access Bearer response to MME.
5. First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink
Data Report) towards SGW-C.
6. On arrival of Sx Report Request message, the SGW-C initiates Downlink Data Notification request
message towards MME.
7. SGW-C sends Sx Report Response message towards SGW-U.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
500
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
Sx Interface

8. Downlink Data Notification Acknowledgment is received from MME with DDN Delay Timer value.
This timer value will be saved for this peer , and now onwards every Downlink Data notification that
we initiate should be after this delay for that peer.
9. On success paging, MME sends a Modify bearer request to the SGW with eNodeB TEIDs that sets up
the S1-U connection at the SGW.
10. SGW-C sends Sx Modification Request with updated FAR for new TEID information to SGW-U.
SGW-U can now forward all the buffered data to UE via eNodeB.
11. SGW-C sends Modify Bearer Response to MME.
12. SGW-U sends Sx Modification Response to SGW-C.
13. MME sends Release Access Bearer Request to SGW-C to release downlink remote TEIDs of all the
bearers for that UE.
14. On arrival of Release Access Bearer Request, SGW-C inform the same to SGW-U via updating FAR
with Apply Action as BUFFER in Sx Modification Request for all the PDNs.
15. SGW-U send Sx Modification Response after applying Buffering in SGW-U for corresponding PDN.
16. SGW-C sends Release Access Bearer Response to MME.
17. First Downlink data arriving in SGW-U triggers Sx Report Request (with Report Type as Downlink
Data Report) towards SGW-C.
18. On arrival of Sx Report Request message, SGW-C starts DDN Delay Timer. On DDN Delay timer
expiry SGW-C Initiates Downlink Data Notification message towards MME.

Sx Interface
Sx Session Level Reporting Procedure
Detection of first Downlink Data for Idle-Mode UE (by SAEGW-U):
When SAEGW-U receives the downlink packet but no S1-bearer for transmission and the buffering is performed
by SAEGW-U, it reports the detection of first downlink data to SAEGW-C, for the purpose of paging the UE.
PFCP Session Report Request
The PFCP Session Report Request is sent over the Sxab interface by the User Plane function to report
information related to a PFCP session to the Control Plane function.

Information P Condition / Appl. IE Type

elements Comment
Sxa Sxb Sxc N4

Report Type M This IE X X X X Report

shall Type
indicate the
type of the
report.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
501
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
Sx Interface

Downlink C This IE X - - X Downlink

Data Report shall be Data Report
present if
the Report
Type
indicates a
Downlink
Data
Report.

Downlink Data Report IE within PFCP Session Report Request

The Downlink Data Report grouped IE is encoded as shown in the following table.

Octet 1 and Downlink Data Report IE Type = 83 (decimal)

2

Octets 3 and Length = n

4

Information P Condition / Appl. IE Type

elements Comment
Sxa Sxb Sxc N4

PDR ID M This IE X - - X PDR ID

shall
identify the
PDR for
which
downlink
data packets
have been
received at
the UP
function.
More than
one IE with
this type
may be
included to
represent
multiple
PDRs
having
received
downlink
data
packets.

Notification to User Plane Function for DDN Failure

The Control Plane function notifies User Plane function for any failure so that buffered packets can be dropped
and DDN related flags can be reset through DROBU flag in PFCP Sx Modification message.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
502
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
Limitations

PFCPSMReq-Flags C DROBU (Drop Buffered Packets): The CP function

shall set this flag if the UP function is requested to
drop the packets currently buffered for this PFCP
session (see NOTE 1).

Limitations
Following are the known limitations of this feature:
• SAEGW Buffering is done for five data packets per PDN session.
• DDN profile configuration is not supported.
• Support for buffered data (data packet stream) that get deleted due to Flow Idle Timeout or other cases,
is not present.

SAEGW Idle Buffering with DDN Delay and DDN Throttling

Support Configuration
DDN Throttling for Release 10 Compliant MME
DDN throttling is enabled through Call Control Profile by providing the ARP value. For example, if the ARP
value provided is 10, then all bearers with ARP value between 10-15 are treated as low priority bearers and
are given throttling treatment. Throttling would not be enabled if ARP value is not provided through S-GW
service configuration. Also, ARP IE in DDN message towards MME would not be included unless DDN
throttling is configured using S-GW service. If MME is Release 10 compliant, the user need not configure
the duration value as the DDN Acknowledgment would have the throttling IE. Otherwise, throttling can be
enabled at S-GW by setting the duration value. If it’s set to 0, S-GW would apply throttling recurringly. To
enable throttling only for a given duration of time (in non Rel-10 compliant MME), user needs to set the value
in hours and minutes. From the time of configuration, throttling would be applied at S-GW until the timer
duration expires. For example, if user sets hours = 10, minutes = 30, S-GW would apply throttling for next
10 hours 30 minutes.
On re-configuration, all the parameters will be set with new values, but they will be applicable only from the
next recalibration except from polling time and time factor.
Use the following configuration to configure DDN throttling for release 10 MME:
configure
context context_name
sgw-service service_name
[ no ] ddn throttle arp-watermark arp_value
end
NOTES:
• arp-value: Valid ARP value between 1 and 15. All the packets which have ARP greater than the
configured values will be throttled as per the throttling factor.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
503
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
DDN Throttling for non-Release 10 Compliant MME

DDN Throttling for non-Release 10 Compliant MME

Use the following configuration to configure DDN throttling for a non-release 10 MME:
configure
context context_name
sgw-service service_name
ddn throttle arp-watermark arp_value [ rate-limit limit time-factor
seconds throttle-factor percent increment-factor percent [ poll-interval seconds
] throttle-time-sec seconds [ throttle-time-min minutes ] [
throttle-time-hour hour ] stab-time-sec seconds [ stab-time-min minutes ] [
stab-time-hour hour ]
no ddn throttle
end
NOTES:
• rate-limit: DDN permitted per second.
• time-factor: Time period in seconds over which SGW makes throttling decision ( valid range 1-300
seconds.
• arp-value: Valid ARP value between 1 and 15. All the packets which have arp greater than the configured
values will be throttled as per the throttling factor.
• throttling-factor: Percentage of DDN to be dropped upon detecting DDN surge (valid range between
1-100).
• throttling-time-sec: Time period in seconds over which DDN are throttled at SGW (valid range between
0-59 seconds).
• throttling-time-min: Time period in minutes over which DDN are throttled at SGW (valid range between
0-59 minutes).
• throttling-time-hour: Time period in hours over which DDN are throttled at SGW (valid range between
0-310 hours).
• increment-factor: Percentage value by which throttling factor is incremented dynamically, if existing
throttling factor is insufficient to curb the DDN surge.
• poll-interval: Time in seconds (optional argument, default value = 1 second, poll interval < time-factor
)
• stab-time-sec/min/hours: Stabilization time factor, time period over which if DDN rate returns to normal,
then throttling need not be applied over entire throttling time period.

DDN throttling for non-Release-10 compliant MME makes use of existing Release-10 throttling implementation
at SGW. By providing a configuration mechanism for SGW service, operator can still apply ddn throttling
without needing any feedback from MME. Some salient points of this feature are described below:
1. The CLI configuration is applied per MME/S4-SGSN. Throttling parameters are tracked independently
per MME/S4-SGSN.
2. On configuring this feature through CLI, demuxmgr polls each sessmgr for number of DDNs sent. By
default, polling is done every second. This time interval can be changed by configuring the poll-interval
time. Greater the poll interval time, lesser the number of internal messages within the chassis. However,
it would take longer to detect a DDN surge.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
504
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
Show Commands Input and/or Outputs

3. By configuring time-factor, operator can specify the time interval for S-GW to apply throttling, if needed.
It allows for some surge of DDNs if the net DDN rate is within specified limit over time-factor time
interval. For example, time-factor= 10 seconds, ddn rate = 1000, poll interval = 2 seconds. Demux would
poll each sessmgr every 2 seconds. Acceptable DDN rate limit is 1000*10 = 10000 DDNs every 10
seconds. Say after 2 seconds, 4000 DDNs were sent, in that case S-GW wouldn’t apply throttling till rate
limit of 10000 DDNs is crossed within time period of 10 seconds. This allows for intermittent bursts of
DDNs.
4. DDN rate limit is configured through CLI. For example, if DDN rate limit is 1000 and poll interval = 1
second, time-factor = 5 seconds, then acceptable rate limit is 5000 DDNs over 5 seconds. If the number
of DDNs sent by S-GW is greater than 5000 after 5 seconds, demuxmgr would ask all sessmgrs to initiate
throttling.
5. Percentage of DDNs to be throttled is configured through throttling-factor.
6. Operator can specify increment-factor to increment throttling factor if existing throttling factor is insufficient
to curb the DDN surge. For example, if throttling-factor = 10%, ddn-rate = 1000, increment-factor=10%.
Once throttling is applied, S-GW drops ~10% DDNs. However, if DDN rate is still greater than 1000,
S-GW would increase throttling-factor to 20%. If this is still not sufficient, it would be incremented to
30%. After incrementing throttling factor, if number of DDNs dropped are greater than expected,
throttling-factor would then be decrement by increment-factor. E.g. in this case, after increasing throttling
factor to 30%, if DDNs sent is less than 1000 per second (taking time-factor and poll-interval into
consideration), throttling factor would be decremented to 20. The cap for decrementing throttling-factor
would be the configured value (10% in this case).
7. Operator can configure the time duration for which throttling is applicable at S-GW. This could be a large
value in order of days (for example: 10 days or 240 hours). The operator has an option to stop throttling
if DDN rate is well under control by configuring stabilization time factor. In such a case, DDNs won’t be
needlessly dropped. For example, throttling-time =10 days, stab-time = 8 hours. After S-GW starts DDN
throttling, in a time span of 8 hours, DDNs sent + DDNs dropped < ddn-rate * 8 hours, throttling would
be stopped.

Show Commands Input and/or Outputs

This section provides information regarding show commands and their outputs in support of the feature.

show subscribers user-plane-only-full all

The output of this command displays the following fields in support of this feature:
• buffered pkts
• buffered bytes
• buffer overflow drop pkts
• buffer overflow drop bytes

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
505
 Cisco Confidential - Limited Release
SAEGW Idle Buffering with DDN Delay and DDN Throttling
show subscribers user-plane-only-full all

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
506
 Cisco Confidential - Limited Release

CHAPTER 68
Self-overload Detection and Admission Control
of Sx at UP
• Revision History, on page 507
• Feature Description, on page 507
• Configuring Overload Control at User Plane, on page 508
• Monitoring and Troubleshooting, on page 510

Revision History
Revision Details Release

First introduced. 21.15.1

Feature Description
Overload detection and control at User Plane (UP) is implemented using the eMPS functionality. During an
overload scenario at Sx, the Session Establishment and Modification requests that are received at Sx (UP) are
rejected for all non-eMPS subscribers.
Currently, overload control is supported for Sx Control Plane (CP). To support eMPS at UP, the CP adds the
eMPS value to Message Priority IE in the PFCP header and sends the message over to UP.
The UP, on receipt of the Sx Session Establishment/Modification request, performs an overload check. If the
detected system load is normal, the session establishment/modification is allowed, and the session is marked
as a priority session based on the MP flag set in the PFCP header.
If the detected system load is overloaded, the Sx Session Establishment/Modification is rejected for all eMPS
subscribers.
The system load level is determined by the following factors:
• System Utilization (CPU, Memory, and Licenses)
• Session Manager Utilization (CPU and Memory)
• VPP-CPU Utilization

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
507
 Cisco Confidential - Limited Release
Self-overload Detection and Admission Control of Sx at UP
Limitations

Limitations
The following are the known limitations of the feature:
• Data throttling is not supported.
• Alarms are not supported.
• Bulk statistics are not supported.
• No support for handling APN-based emergency calls in a Pure-S scenario. Other emergency calls such
as – IMSI-based and IMEI-valid based are handled.
• Only self-overload protection is supported in this release.
• User Plane ICSR not supported in this release.
• Impact on existing calls: If userplane-overload-control-profile is configured and associated to user
plane service. Also, if the system moves to overload condition and the user plane service rejects SX
Session Establishment and SX session modification messages, this leads to call cleanup/drop of relevant
calls triggering SX session modification messages. This behavior continues until the system returns to
the normal load condition.

Configuring Overload Control at User Plane

eMPS Profile Creation and Association to S-GW and P-GW Services of Control
Plane

Important This configuration must be done before configuring an overload control profile at UP.

configure
emps-profile profile_name
earp earp_value
end
configure
context context_name
sgw-service service_name
associate emps-profile profile_name
exit
pgw-service service_name
associate emps-profile profile_name
end

Configuring the Overload Control Profile at UP

Use the following commands to configure overload control profile.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
508
 Cisco Confidential - Limited Release
Self-overload Detection and Admission Control of Sx at UP
Configuring Overload Threshold Parameters

configure
userplane-overload-control-profile profile_name
end

Configuring Overload Threshold Parameters

Use the following commands to configure overload threshold parameters.
configure
userplane-overload-control-profile profile_name
overload-threshold system lower-limit limit_value upper-limit limit_value
sessmgr lower-limit limit_value upper-limit limit_value vpp-cpu lower-limit
limit_value upper-limit limit_value
end
NOTES:
• overload-threshold: Configures Overload thresholds limits for system, sessmgr and vpp-cpu.
• system: Configures overload system threshold after which node moves to self-protection mode.
• vpp-cpu: Configures the overload vpp-cpu threshold after which node moves to self-protection mode.
• sessmgr: Configures the overload threshold for session manager after which node moves to self-protection
mode.
• upper-limit limit_value: Configures overload vpp-cpu threshold L2 after which node moves to
self-protection mode. Default limit value is 60%.
• lower-limit limit_value: Configures overload vpp-cpu threshold L1 after which node moves to
self-protection mode. Default limit value is 50%.

Configuring System Weightage Parameters

Use the following commands to configure session manager weightage parameters.
configure
userplane-overload-control-profile profile_name
system-weightage system-cpu-utilization utilization_value
system-memory-utilization utilization_value license-session-utilization
utilization_value
end
NOTES:
• system-weightage: Configures system weightage for various overload control parameters. Total weightage
of all the parameters should be 100. The default values are 40% weightage to system-cpu-utilization,
30% weightage to system-memory-utilization and 30% weightage to license-session-utilization.
• system-cpu-utilization: Configures system CPU utilization weightage in percentage. Default weightage
in overload factor is 40%.
• system-memory-utilization: Configures system memory utilization weightage in percentage. Default
weightage in overload factor is 30%.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
509
 Cisco Confidential - Limited Release
Self-overload Detection and Admission Control of Sx at UP
Configuring Session Manager Weightage Parameters

• license-session-utilization: Configures license session utilization weightage for User Plane service in
percentage. Default weightage in overload factor is 30%.

Configuring Session Manager Weightage Parameters

Use the following commands to configure session manager weightage parameters.
configure
userplane-overload-control-profile profile_name
sessmgr-weightage sessmgr-cpu-utilization utilization_value
sessmgr-memory-utilization utilization_value
end
NOTES:
• sessmgr-weightage: Configures sessmgr weightage for various overload control parameters. Total
weightage of all the parameters should be 100. The default values are 35% weightage to
sessmgr-cpu-utilization and 65% weightage to sessmgr-memory-utilization.
• sessmgr-cpu-utilization: Configures session manager CPU utilization weightage in percentage. Default
weightage in overload factor is 35%.
• sessmgr-memory-utilization: Configures session manager memory utilization weightage in percentage.
Default weightage in overload factor is 65%.

Associating an Overload Control Profile with a User Plane Service

Use the following commands to associate the Overload Control profile to a use plane service.
configure
context context_name
user-plane-service service_name
[ no ] associate userplane-overload-control-profile profile_name

NOTES:
• associate: This command associates the user plane overload control profile with a user plane service.

Monitoring and Troubleshooting

Show Commands Input and/or Outputs
This section provides information regarding show commands and their outputs in support of the feature.

show user-plane-service name name

The following fields are displayed in support of this feature:
• Service name
• Service-Id

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
510
 Cisco Confidential - Limited Release
Self-overload Detection and Admission Control of Sx at UP
show user-plane-service statistics name user_plane_service_name

• Context
• Status
• PGW Ingress GTPU Service
• SGW Ingress GTPU Service
• SGW Egress GTPU Service
• Control Plane Tunnel GTPU Service
• Sx Service
• Control Plane Group
• Userplane Overload Control Profile
• Fast-Path service

show user-plane-service statistics name user_plane_service_name

The following fields are displayed in support of this feature:
• Overload Control Information
• Current Overload Factor System: Average of all user plane service values
• Current Overload Factor SessMgr
• Current Overload Factor VPP-CPU
• No of times Overload Threshold Reached
• No of Session Eshtablishment Req rejected during overload
• No of Session Modif Req rejected during overload
• No of eMPS Session Eshtablishment Req allowed during overload
• No of eMPS Session Modif Req allowed during overload

show userplane-overload-control-profile name name

The following fields are displayed in support of this feature:
• User Plane Overload Control Profiles
• User Plane Overload Control Profile Name
• System Weightage and Thresholds:
• CPU Utilization Weightage
• Memory Utilization Weightage
• License Session Utilization Weightage
• System Threshold Lower Limit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
511
 Cisco Confidential - Limited Release
Self-overload Detection and Admission Control of Sx at UP
show userplane-overload-control-profile name name

• System Threshold Upper Limit

• Sessmgr Weightage and Thresholds:

• CPU Utilization Weightage
• Memory Utilization Weightage
• Sessmgr Threshold Lower Limit
• Sessmgr Threshold Upper Limit

• VPP Weightage and Thresholds:

• VPP Utilization Weightage
• vpp-cpu Threshold Lower Limit
• vpp-cpu Threshold Upper Limit

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
512
 Cisco Confidential - Limited Release

CHAPTER 69
Smart Licensing
• Revision History, on page 513
• Overview, on page 513
• Configuring Smart Licensing, on page 518
• Monitoring and Troubleshooting Smart Licensing, on page 519

Revision History
Revision Details Release

First introduced. 21.21

Overview
Ultra Packet Core CUPS supports Smart Licensing. Smart Licensing is a cloud-based approach to licensing
that simplifies the purchase, deployment, and management of Cisco software assets. Entitlements are purchased
through your Cisco account via Cisco Commerce Workspace (CCW) and immediately deposited into your
Virtual Account for usage. This eliminates the need to install license files on every device. Products that are
smart-enabled, communicate directly to Cisco to report consumption. A single location is available to customers
to manage Cisco software licenses—the Cisco Smart Software Manager (CSSM). License ownership and
consumption are readily available to help make better purchase decision based on consumption or business
need.
See https://www.cisco.com/c/en/us/buy/smart-accounts/software-licensing.html for more information about
Cisco Smart Licensing.

Comparison Between Legacy Licensing and Smart Licensing

Cisco employs two types of license models - Legacy Licensing and Smart Software Licensing. Legacy
Licensing consists of software activation by installing Product Activation Keys (PAK) on to the Cisco product.
A Product Activation Key is a purchasable item, ordered in the same manner as other Cisco equipment and
used to obtain license files for feature set on Cisco Products. Smart Software Licensing is a cloud-based
licensing of the end-to-end platform leveraging few tools that authorize and deliver license reporting. Smart
Software Licensing functionality incorporated into StarOS completes the product registration, authorization
resulting in reporting services available to the end customer.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
513
 Cisco Confidential - Limited Release
Smart Licensing
Cisco Smart Software Manager

Evaluation Period
A 90-day evaluation period is granted for all licenses in use. During this period, feature licenses can be used
without limitation, and up to one counting license each can be used. The evaluation period ends when the
system registers successfully with the CSSM or Cisco.com. Licensed functionality is blocked when this 90-day
period expires.
CUPS performs license enforcement for on/off feature licenses. Each on/off feature license is tied to service
licenses, which potentially use those on/off features. When an Out of Compliance (OOC) is detected for an
on/off license, new calls for the corresponding services will be dropped, subject to the following conditions:
• Each on/off feature license is given a 90-day grace (evaluation) period. During this period, the system
generates SNMP traps to inform of the unavailability of valid licenses. To resolve the OOC, corrective
action is needed such as purchasing and registering licenses for this feature, or disabling the feature.
• If the feature is still OOC after the 90-day grace period, CUPS enforces the OOC state based on a
predefined policy for each license. If enforcement is required, new calls for the services corresponding
to the on/off licenses are dropped.

The following CLI commands can be used to display details about the enforcement of Smart Licenses in use:
show license enforcement policy
show license enforcement status [ allowed | blocked ] [ feature | service
]

Cisco Smart Software Manager

Cisco Smart Software Manager (CSSM) enables the management of software licenses and Smart Account
from a single portal. The interface allows you to activate your product, manage entitlements, and renew and
upgrade software. A functioning Smart Account is required to complete the registration process. To access
the Cisco Smart Software Manager, see https://software.cisco.com.

Smart Accounts/Virtual Accounts

A Smart Account provides a single location for all Smart-enabled products and entitlements. It helps speed
procurement, deployment, and maintenance of Cisco Software. When creating a Smart Account, you must
have the authority to represent the requesting organization. After submitting, the request goes through a brief
approval process.
A Virtual Account exists as a sub-account withing the Smart Account. Virtual Accounts are a customer-defined
structure based on organizational layout, business function, geography or any defined hierarchy. They are
created and maintained by the Smart Account administrator.
See https://software.cisco.com to learn about, set up, or manage Smart Accounts.

Smart Licensing Mode

The Smart Licensing Mode is categorized as follows:
• Reporting Licenses (Parent Licenses): The Parent Licenses are reported to backend license server
(CSSM) and accounted for usage of licenses. For each Parent Licenses, the entitlement tags are created
and the same is used to identify the type service or feature.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
514
 Cisco Confidential - Limited Release
Smart Licensing
Request a Cisco Smart Account

• Non-Reporting Licenses (Child Licenses): The Child Licenses are not reported to backend license
server (CSSM) and these licenses are enabled by default with the Parent Licenses. For Child Licenses,
the entitlement tags are not created.

That is to say, Smart License enables all Parent and Child Licenses based on the Product Type that is configured.
However, the reporting is done only for Parent Licenses.
The state of Smart Licensing Agent is persistent across reboot and crashes.

Request a Cisco Smart Account

A Cisco Smart Account is an account where all products enabled for Smart Licensing are deposited. A Cisco
Smart Account allows you to manage and activate your licenses to devices, monitor license use, and track
Cisco license purchases. Through transparent access, you have a real-time view into your Smart Licensing
products. IT administrators can manage licenses and account users within your organization's Smart Account
through the Smart Software Manager.

Step 1 In a browser window, enter the following URL:

https://software.cisco.com

Step 2 Log in using your credentials, and then click Request a Smart Account in the Administration area.
The Smart Account Request window is displayed.

Step 3 Under Create Account, select one of the following options:

• Yes, I have authority to represent my company and want to create the Smart Account – If you select this
option, you agree to authorization to create and manage product and service entitlements, users, and roles on behalf
of your organization.
• No, the person specified below will create the account – If you select this option, you must enter the email address
of the person who will create the Smart Account.

Step 4 Under Account Information:

a) Click Edit beside Account Domain Identifier.
b) In the Edit Account Identifier dialog box, enter the domain, and click OK. By default, the domain is based on the
email address of the person creating the account and must belong to the company that will own this account.
c) Enter the Account Name (typically, the company name).
Step 5 Click Continue.
The Smart Account request will be in pending status until it has been approved by the Account Domain Identifier. After
approval, you will receive an email confirmation with instructions for completing the setup process.

Software Tags and Entitlement Tags

Tags for the following software and entitlements have been created to identify, report, and enforce licenses.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
515
 Cisco Confidential - Limited Release
Smart Licensing
Software Tags and Entitlement Tags

Software Tags
Software tags uniquely identify each licenseable software product or product suite on a device. The following
software tags exist for CUPS.

Product Type / Description Software Tag

CUPS_CP regid.2020-08.com.cisco.CUPS_CP,
1.0_7afd7a3c-38dd-4a04-aecc-26df25029649
4G CUPS - Control Plane

CUPS_UP regid.2020-08.com.cisco.CUPS_UP,
1.0_fd28551c-a541-4902-87af-bba2d6b33cf1
4G CUPS - User Plane

Reporting (Parent) Entitlement Tags for CUPS_CP

The following entitlement tags indentify licenses in use for each product type.

License Display Entitlement Tag License Reporting Tag Name

Name/Description Type Slab

4G CUPS CP 1K regid.2020-08.com.cisco. Counting 1K L_CUPS_CP _

L_CUPS_CP_SAE_1K, SAE_1K
4G CUPS Control
1.0_a84e70b6-d3f9-41c9
Plane 1K Sessions
-8449-4b7bb7426b30

Reporting (Parent) Entitlement Tags for CUPS_UP

The following entitlement tags indentify licenses in use for each product type.

License Display Entitlement Tag License Reporting Tag Name

Name/Description Type Slab

4G CUPS UP 1K regid.2020-08.com.cisco. Counting 1K L_CUPS_UP

L_CUPS_UP_SAE_1K, _SAE_1K
4G CUPS User Plane
1.0_41005ab7-1ad0-46ac
1K Sessions
-905b-c3c5ed402981
4G CUPS UP regid.2020-08.com.cisco. On/Off 1/0 F_CUPS_UP_INS
Instances F_CUPS_UP_INS,
1.0_897c46a0-04b5-4fdb
4G CUPS User Plane
-bedd-9d5fb75bdb76
Instances

Non-reporting (Child) License List

In this release, the following Child Licenses are enabled by default when the Parent Licenses are enabled.

License Description License Type

PGW 1k Sessions Counting
SGW 1k Sessions Counting
GGSN 1k Sessions Counting

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
516
 Cisco Confidential - Limited Release
Smart Licensing
Software Tags and Entitlement Tags

License Description License Type

Per Subscriber Stateful Firewall 1k Sessions Counting
ENAT 1k Sessions Counting
Enhanced Charging Bundle 1 Counting
Enhanced charging bundle 2 On/Off
Dynamic policy interface On/Off
Enhanced LI service On/Off
Lawful intercept On/Off
Session recover On/Off
Radius AAA server group On/Off
IPv6 On/Off
Intelligent Traffic Control On/Off
DIAMETER Closed-Loop Charging Interface On/Off
Per-Subscriber Traffic Policing/Shaping On/Off
Dynamic Radius extensions (CoA and PoD) On/Off
Proxy MIP On/Off
FA On/Off
IPSec On/Off
Inter-Chassis Session Recovery On/Off
ICSR/SR Performance Improvements On/Off
ICSR Enhanced Recovery for Data and Control Plane, 1K Sessions On/Off
MPLS On/Off
TACACS+ On/Off
NAT/PAT With DPI On/Off
Rate Limiting Function (Throttling) On/Off
Overcharging Protection for EPC-GW On/Off
Overcharging Protection Upgrade for EPC-GW On/Off
ADC Trigger Over Gx, 1K Sessions On/Off
Gx Based Virtual APN Selection, 1K Sessions On/Off
EPC-GW Support for Wi-Fi Integration, 1K Sessions On/Off
EPC-GW Non-Standard QCI Support, 1K Sessions On/Off
Local Policy Decision Engine On/Off
Header Enrichment On/Off

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
517
 Cisco Confidential - Limited Release
Smart Licensing
Configuring Smart Licensing

License Description License Type

HTTP Header Encryption On/Off
HTTP Header Enrichment and Encryption On/Off
Broadcast & Multicast Services On/Off
Integrated Content Filtering Provisioned Service On/Off
Application Detection and Control 1k Sessions Counting
5G NSA Feature Set 100K Sess VPCSW Active 1k Sessions Counting
5G NSA Enablement Fee, Network Wide On/Off
Multimedia Priority Service Feature Set,1K Sessions On/Off
EPC Gw VoLTE enhancements On/Off
DNS Snooping On/Off

Configuring Smart Licensing

Before you begin, ensure you have:
• Created a Smart Licensing account on https://software.cisco.com.
• Registered your products on https://software.cisco.com using the Product Instance Registration tokens
created as part of Smart Account/Virtual Account.
• Enabled a communication path between the StarOS system to the CSSM server or Cisco.com.

Enable Smart Licensing

By default, Smart Licensing is disabled in CUPS. To enable Smart Licensing, enter the following Config
mode commands:
configure
license smart product { cups-cp | cups-up }
license smart enable
end
NOTE: Before enabling Smart Licensing, Product Type must be configured to enable default licenses that
are based on product type.
Enter the following command to verify the configuration:
show configuration | grep license

Register the Device with Cisco

Using the Product Instance Registration token ID provided when you registered the products on
https://software.cisco.com, register the system using the following Exec mode command:
license smart register idtoken token

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
518
 Cisco Confidential - Limited Release
Smart Licensing
Monitoring and Troubleshooting Smart Licensing

The system now automatically reports entitlement usage count to the CSSM server and receives a compliance
status. This also removes the system from "Evaluation Mode".
To show the compliance status, enter any of the following Exec mode commands:
show license status
show license summary
show license statistics
The registration for the system is renewed automatically every 180 days. If needed, use the following Exec
mode command to renew the registration information manually:
license smart renew id
The license authorization for the system is renewed automatically every 30 days. If needed, use the following
Exec mode command to renew the license authorization manually:
license smart renew auth
To unregister a device, enter the following Exec mode command:
license smart deregister

Changing Smart Transport URL

Smart Agent uses Smart Transport to communicate to Cisco CSSM server. Smart Transport uses the configured
URL to identify destination URL where CSSM is reachable. This will not initiate any communication with
Cisco. If needed, enter the following Configuration mode commands:
configure
license smart transport smart
license smart url https_link

Handling Out of Compliance

If there are not enough licenses in the virtual account for a given SKU, CSSM sends an Out Of Compliance
(OOC) message to the device. The system stops allowing additional sessions until the OOC state is cleared.
The OOC state is cleared when the device receives an authorized response.

Monitoring and Troubleshooting Smart Licensing

Enter the following Exec mode command to verify the Smart Licensing configuration:
show configuration | grep license
The following Exec mode commands display information about Smart Licensing:
show license { all | enforcement | smart-tags | statistics | status |
summary | tech-support | udi | usage }
NOTES:
• all - Shows a superset of information that includes show status, show usage, show UDI, as well as the
Smart Licensing agent version.
• enforcement { policy | status [ allowed | blocked ] [ feature | service ] } - Shows the enforcement
policy applied or current enforcement status of Smart Licenses. Status information can be filtered to

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
519
 Cisco Confidential - Limited Release
Smart Licensing
Monitoring and Troubleshooting Smart Licensing

show only the licenses which are currently allowed or blocked, or by type (feature license or service
license).
• smart-tags [ feature | service ] - Shows the features and services that are currently supported and the
corresponding Smart Entitlement Tag.
• statistics [ verbose ] - Shows individual feature license status.
• status - Shows overall Smart Licensing status information.
• summary - Shows summary of Smart Licensing status.
• tech-support - Shows information useful for debugging issues with Smart Licensing.
• udi - Shows details for all Unique Device Identifiers (UDI).
• usage - Shows the usage information for all entitlements that are currently in use.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
520
 Cisco Confidential - Limited Release

CHAPTER 70
Static and Predefined Rule Match Support for
Shallow Packet Inspection
• Revision History, on page 521
• Feature Description, on page 521
• How It Works, on page 522
• Monitoring and Troubleshooting, on page 523

Revision History
Revision Details Release

Data Path with Basic SPI. 21.8 (4/3/2018)

The following support are fully qualified in this release:
• SPI with static rules
• SPI with predefined rules

First introduced. 21.6

Data Path with Basic SPI.
The following support are not fully qualified in this release:
• SPI with static rules
• SPI with predefined rules

Feature Description
This feature adds support to check different data statistics related to the node or ongoing sessions in the CUPS
deployment.
To support this functionality, a new keyword “real-time” has been added to the following CLI commands:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
521
 Cisco Confidential - Limited Release
Static and Predefined Rule Match Support for Shallow Packet Inspection
How It Works

• show apn statistics real-time - Displays the aggregated data and control statistics across all APN’s from
all user-planes connected to this control plane.
• show apn statistics real-time all - Displays independently per APN, the data and control statistics from
all user-planes connected to this control plane.
• show apn statistics real-time name - Displays the data and control statistics by fetching data from all the
user-planes for a given APN.

Important For this release, only the following eight counters are supported:
• Uplink Bytes
• Downlink Bytes
• Uplink Packets
• Downlink Packets
• Dropped Uplink Bytes
• Dropped Downlink Bytes
• Dropped Uplink Packets
• Dropped Downlink Packets

How It Works
The following points describe briefly how the SPI feature works:
• The static and predefined rule policies, which are available on the Control-Plane, are percolated to the
User-plane based on the rulebase that is associated to the subscriber. This information is translated in
the form of a PDR on the Control-Plane.
Static and predefined rules on the Control-Plane that are translated to PDRs and sent to convert static
rules into a rulebase PDR while the predefined rules would be translated as PDR IDs, individual PDR
IDs and sent to the User-plane for activation. This is how a set of subscriber policies would be defined
in the User-plane.
The session establishment associates the predefined and static rule that is available to the subscriber.
This handles the implementation of policies that are associated for a subscriber.
• The PDR match maps the data packet against the filters specified in the PDI field of the applicable PDRs.
When all filter conditions are matched, the packet is matched to the PDR. Based on the FAR ID, the
action to perform on the packet is known. Accordingly, the service chain is updated and executed.
• For static and predefined rules, a unique URR is generated based on the combination of QCI, service-ID,
and rating-group is configured on the Control-Plane. This URR is passed on the User-plane and forwarding
actions are implemented
Based on this information, policing and charging actions are implemented for the packet, including
updating URRs and applying QERs.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
522
 Cisco Confidential - Limited Release
Static and Predefined Rule Match Support for Shallow Packet Inspection
Monitoring and Troubleshooting

For matched PDRs, the forwarding action is to either “allow” or “discard” a packet.

Monitoring and Troubleshooting

This section provides information regarding show commands and/or their outputs in support of this feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show subscribers user-plane-only full all

The output of this command has been enhanced to include the following new fields and values in support of
this feature.
• Static & Predef Rule Match stats
• Rule Name
• Pkts-Down
• Bytes-Down
• Bytes-Up
• Hits
• Match-Bypassed

• Dynamic Rule Match stats

• PDR Id
• Pkts-Down
• Bytes-Down
• Pkts-Up
• Bytes-Up
• Hits
• Match-Bypassed

show subscribers user-plane-only callid <callid> pdr full all

The output of this command has been enhanced to include the following field in support of this feature.
Rule Name
This field is displayed only for predefined rules.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
523
 Cisco Confidential - Limited Release
Static and Predefined Rule Match Support for Shallow Packet Inspection
show subscribers user-plane-only seid <seid> pdr full all

show subscribers user-plane-only seid <seid> pdr full all

The output of this command has been enhanced to include the following field in support of this feature.
Rule Name
This field is displayed only for predefined rules.

show subscribers user-plane-only callid <callid> pdr id <id>

The output of this command has been enhanced to include the following field in support of this feature.
Rule Name
This field is displayed only for predefined rules.

show subscribers user-plane-only seid <seid> pdr id <id>

The output of this command has been enhanced to include the following field in support of this feature.
Rule Name
This field is displayed only for predefined rules.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
524
 Cisco Confidential - Limited Release

CHAPTER 71
Static IP Assignment from RADIUS
• Feature Description, on page 525
• How it Works, on page 525

Feature Description
In this feature, static IP address for a subscriber is assigned from RADIUS server during the initial authentication
procedure. This feature leverages the static IP address (UE-requested) functionality available in CUPS.

How it Works
After the RADIUS server assigns static IP address to the session, the User Plane selection of static session is
fixed as per chunk allocation to User Plane from the User Plane group that is associated to an APN.
If same static IP address range is used across multiple APN, then it's recommended to use same User Plane
group in those APN.
For more information on static IP pool management, refer the IP Pool Management chapter in the Ultra Packet
Core CUPS User Plane Administration Guide or Ultra Packet Core CUPS Control Plane Administration
Guide.

Limitations
The following are the known limitations of the feature:
• Static IP Address Pool assignment from RADIUS isn't supported as part of this feature.
• SAEGW-C doesn't support IPv4v6 PDN type call with static address received from RADIUS, even if
one of the IP addresses (either IPv4 or IPv6, or both) is static address.
• SAEGW-C doesn't support allow-static type pool configuration.
• Multi-PDN call with static IP address allocation isn't supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
525
 Cisco Confidential - Limited Release
Static IP Assignment from RADIUS
Limitations

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
526
 Cisco Confidential - Limited Release

CHAPTER 72
Suspend and Resume Notification for Pure-S
Calls
• Revision History, on page 527
• Feature Description, on page 527
• How It Works, on page 527

Revision History
Revision Details Release

First introduced. 21.15.1

Feature Description
Suspend and Resume Notifications for Pure-S calls are now supported in the CUPS architecture. The User
Plane (UP) and Control Plane (CP) communicate through the Sx Establishment/Modification request when
a Suspend/Resume notification is received.
Ongoing streams are maintained on the UP. When a Suspend/Resume notification is received, the CP changes
the FAR action on UP through the Sx Modification request message. In response, the UP sets the appropriate
FAR action.
On receiving a Modify Bearer request after a suspend notification, if an eNodeB TEID exists in the MBReq,
the mode is set to Forward in the FAR. If the eNodeB TEID does not exist, then the mode is set to BUFFER.

How It Works
For a Suspend notification, downlink data is suspended by setting downlink FAR action to DROP. For a
Resume notification, downlink data is buffered by setting downlink FAR action to BUFFER.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
527
 Cisco Confidential - Limited Release
Suspend and Resume Notification for Pure-S Calls
Call Flows

Call Flows
Suspend Notification
On receipt of a Suspend notification in Pure-S call, the SGW-C updates the Download FAR action by sending
Sx Session Modification request to SGW-U with FAR action set as DROP.
The following call flow, at a high level, illustrates the Suspend notification for Pure-S calls

Resume Notification
On receipt of Resume notification in Pure-S call, the SGW-C updates the Download FAR action by sending
Sx Session Modification request to SGW-U with FAR action set as BUFFER.
The following call flow, at a high level, illustrates the Resume notification for Pure-S calls.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
528
 Cisco Confidential - Limited Release
Suspend and Resume Notification for Pure-S Calls
Resume Notification

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
529
 Cisco Confidential - Limited Release
Suspend and Resume Notification for Pure-S Calls
Resume Notification

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
530
 Cisco Confidential - Limited Release

CHAPTER 73
Tariff Time Support
• Revision History, on page 531
• Feature Description, on page 531

Revision History
Revision Details Release

First introduced. 21.13 (2/26/2019)

Feature Description
The Tarrif switch time functionality is applied when a subscriber switches form one tarrif plan to another.
The Tariff-Time-Change AVP is used to determine the tariff switch time, and the Monitoring-Time IE is used
to support the Tarrif Time support functionality.
After a tariff timer expiry, the Gateway accumulates the usage separately in a charging bucket and continues
to consume from the original quota value. At the time of next reporting, (Quota exhausted or another control
events) the Gateway will report both usages (before and after tarrif time change) for the same Charging Bucket.
The first reporting of this charging-bucket will have the Reporting-Reason: Tariff-Time-Change, and the
second bucket will contain the last reporting reason, and the quota usage after the tariff-timer expiry.
The data traffic usage can be split into resource usage before a tariff switch and resources used after a tariff
switch. The Tariff-Change-Usage AVP is used within the Used-Service-Units AVP to distinguish reported
usage before and after the tariff time change.

Limitations
Following are the known limitations of this feature:
• Only one tariff time per RG/Service ID combination is supported.
• Allocation of different quota before and after tariff time change is not supported. This functionality is
not in compliance with the 3GPP stanadards.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
531
 Cisco Confidential - Limited Release
Tariff Time Support
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
532
 Cisco Confidential - Limited Release

CHAPTER 74
URL Blacklisting
• Revision History, on page 533
• Feature Description, on page 533
• How it Works, on page 533
• Configuring URL Blacklisting, on page 535
• Monitoring and Troubleshooting, on page 536

Revision History
Revision Details Release

First introduced. 21.15.1

Feature Description
The URL blacklisting feature regulates the subscriber’s access to view or download content from websites
whose URL or URI has been blacklisted. It uses a database that records a list of URLs that indicates if the
detected URL is categorized to be blocked or not.

How it Works
To enable the URL blacklisting feature on User Plane (UP), URL blacklisting database should be present with
a name “optblk.bin” under flash, or SFTP or under its sub-directory. This database directory path needs to be
configured on user-plane, after user-plane services are brought up.
HTTP Analyzer must be enabled for URL blacklisting. The HTTP analyzer extracts URL information from
the incoming HTTP request data packet. Extracted URL content is compared with the URL Blacklisting
database. Once the incoming HTTP data packet’s URL matches with the database URL entry, that URL is
treated as blacklisted URL and one of the following actions takes place on that HTTP packet.
• Termination of flow
• Packet is discarded

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
533
 Cisco Confidential - Limited Release
URL Blacklisting
Limitations

The URL backlisting configurations must be configured on Control Plane (CP), Rulebase configuration under
Active Charging Service. Additionally, two URL blacklisting methods – Exact and Generic, are supported at
Active Charging Service-level configuration, on CP. These CLI configurations are pushed to UP through PFD
mechanism, during Sx association procedure, to the CP.

Important Blacklisting database(s) are provided by – IWF (Internet Watch Foundation) and NCMEC (National Center
for Missing and Exploited Children). The ASR5500, CUPS UP always receives the blacklisting DB in
Optimized Format (optimized backlisting DB format).

URL Blacklisting Database Upgrade

URL database upgrade is supported in 2 ways:
• Timer-based upgrade or Auto upgrade
• CLI-based upgrade or Manual upgrade

Timer-based or Auto-upgrade
After the database is loaded on the chassis for the first time, a timer, for a duration of 5 minutes, is started.
This process is started to auto upgrade the database.
If at the expiry of the timer, a valid database with higher version is available at the directory path, then database
upgrade procedure is initiated, and a newer version of the database is loaded on the UP chassis.
To upgrade a URL blacklisting database, a higher version of valid URL Blacklisting database with name
“optblk_f.bin” should be present at same directory as that of current database “optblk.bin”.
After the database is upgraded successfully, the earlier “optblk.bin” file gets renamed as “optblk_0.bin” and
“optblk_f.bin” file gets renamed as “optblk.bin”. Here, “optblk_0.bin” file is treated as a backup file of older
database.
If one more upgrade is performed, then “optblk_0.bin” file will be renamed as “optblk_1.bin” file and current
“optblk.bin” will get renamed as “optblk_0.bin”, and so on.
The number of backup files to be stored in the database can be configured using the max-versions CLI on
UP.

CLI-based or Manual Upgrade

In this upgrade method, the CLI command - upgrade url-blacklisting database, upgrades the current database
to a newer version.

Limitations
In this release, session recovery and user-plane redundancy support is not fully qualified.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
534
 Cisco Confidential - Limited Release
URL Blacklisting
Configuring URL Blacklisting

Configuring URL Blacklisting

Loading URL Blacklisting Database on UP
Use the following configuration to load URL blacklisting database on UP.
configure
url-blacklisting database directory path database_directory_path
url-blacklisting database max-versions max_version_value
end
NOTES:
• database directory path: Configures the database directory path.
The database_directory_path is a string of size 1 to 255.
• max-versions: Configures the maximum database upgrade versions.
The max_version_value is an integer from 0 to 3.

Configuration to Enable URL Blacklisting

Use the following configuration to enable URL blacklisting feature on Control Plane.
configure
require active-chargingservice_name
url-blacklisting match-method [ exact | generic ]
rulebase rulebase_name
url-blacklisting action [ discard | terminate-flow ]
end
NOTES:
• match-method [ exact | generic ]: Specifies the match method used for URL blacklisting.
exact: URL Blacklisting perform an exact-match of URL.
generic: URL Blacklisting perform generic-match of URL.
• url-blacklisting action [ discard | terminate-flow ]
discard: Discards the HTTP packet received.
terminate-flow: Terminates the flow of the HTTP packet received.

URL Blacklisting Database Upgrade

Use the following command to upgrade the URL Blacklisting Database.
upgrade url-blacklisting database

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
535
 Cisco Confidential - Limited Release
URL Blacklisting
Monitoring and Troubleshooting

Note This CLI is used for manual upgrade of URL Blacklisting database. File optblk_f.bin must be present in order
to upgrade URL Blacklisting database.

Monitoring and Troubleshooting

This section provides information regarding the CLI command available in support of monitoring and
troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show user-plane-service url-blacklisting database

The following fields are displayed in support of this feature:
• URL Blacklisting Static Rating Databases:
• Last Upgrade Status
• Path
• Database Status
• Number of URLs in DB
• Type
• Version
• Creation Time
• Hostname
• Comment
• Last Access Time
• Last Modification Time
• Last Status Change Time

show user-plane-service url-blacklisting database url database_directory_path

The following fields are displayed in support of this feature:
• URL Blacklisting Static Rating Databases:
• Last Upgrade Status
• Path

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
536
 Cisco Confidential - Limited Release
URL Blacklisting
show user-plane-service url-blacklisting database facility sessmgr all

• Database Status
• Number of URLs in DB
• Type
• Version
• Creation Time
• Hostname
• Comment
• Last Access Time
• Last Modification Time
• Last Status Change Time

show user-plane-service url-blacklisting database facility sessmgr all

The following fields are displayed in support of this feature:
• URL-Blacklisting SessMgr Instance Based Database Configuration
• SessMgr Instance
• BL DB Load Status
• BL DB Version
• Number of URLs
• Checksum

show user-plane-service inline-services info

The following fields are displayed in support of this feature:
• URL-Blacklisting: Enabled
• URL-Blacklisting Match-method: Generic

show user-plane-service rulebase name rulebase_name

The following fields are displayed in support of this feature:
• URL-Blacklisting Action
• URL-Blacklisting Content ID

show user-plane-service inline-services url-blacklisting statistics

The following are displayed in support of this feature:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
537
 Cisco Confidential - Limited Release
URL Blacklisting
show user-plane-service inline-services url-blacklisting statistics rulebase name rulebase_name

• Cumulative URL-Blacklisting Statistics

• Blacklisted URL hits
• Blacklisted URL misses
• Total rulebases matched

show user-plane-service inline-services url-blacklisting statistics rulebase name rulebase_name

The following fields are displayed in support of this feature:
• Rulebase Name
• URL-Blacklisting Statistics
• Blacklisted URL hits
• Blacklisted URL misses

• Total rulebases matched

Bulk Statistics
The following bulk statistics are added to the System schema in support of URL Blacklisting feature:
• url-blacklisting-hits: Indicated the total number of URLs blacklisted.
• url-blacklisting-misses: Indicated the total number blacklisted URLs missed.

SNMP Traps
The following SNMP trap are added in support of this feature:
• BLDBError: Specifies the blacklisting OPTBLDB file error displayed with an error code.
• BLDBErrorClear: Specifies the blacklisting OPTBLDB file error removed.
• BLDBUpgradeError: Specifies the blacklisting OPTBLDB file error displayed with an error code.
• BLDBUpgradeErrorClear: Specifies the Blacklisting OPTBLDB file error removed.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
538
 Cisco Confidential - Limited Release

CHAPTER 75
User Plane Selection based on TAC Range
• Revision History, on page 539
• Feature Description, on page 539
• How It Works, on page 539
• Configuring User Plane Selection based on TAC Range, on page 541

Revision History
Revision Details Release

First introduced. 21.13 (2/26/2019)

Feature Description
With this feature, User Plane group can be selected based on Access Point Name (APN). The ability to
configure Tracking Area Code (TAC) range, in rule combinations in virtual APN selection, helps in giving
more flexible network design for location-based User Plane selection for edge computing and other services.

How It Works
In non-CUPS architecture, Virtual APN selection is based on the following parameters:
• Subscriber IP
• Access-gw-address
• Bearer-access
• cc-behavior
• cc-profile
• domain
• mcc

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
539
 Cisco Confidential - Limited Release
User Plane Selection based on TAC Range
Limitations

• msisdn-range
• pdp-type
• rat-type
• roaming-mode
• serv-gw-plmnid

In CUPS architecture, Virtual APN selection is based on Tracking Area Code range with other options, such
as cc-profile or mcc/mnc.
To support this feature:
• A new CLI keyword is introduced to accommodate new parameter.
• During call processing, incoming tracking area code is compared with the configured tracking area code
range to determine the Virtual APN.

The Tracking Area Code based Virtual APN selection:

• Supports at least 30 tracking-area-code-range configured for Virtual APN.
• Supports overlapping ranges (subset or superset). Duplicate of tracking-area-code-range is not allowed
for different priority.
• Selects a Virtual APN based on CLI configuration and User Plane is selected based on Virtual APN for
a new call based on the tracking-area-code for that UE.
• Supports a combination of tracking-area-code-range and cc-profile in same priority.

Virtual APN functionality includes storing all the Virtual APN selection rules per real/Gn APN. Every rule
has multiple criteria. Rule is identified by preference number. The list of APNs are stored and within APN a
rule is identified using preference number.
New parameter has been introduced to pass Tracking Area Code, received in CSReq (TAI).

Limitations
Following are the known limitations and restriction of this feature.
• New configuration with multiple selection criteria in Virtual APN selection does not work with older
builds/releases. User should have separate copies of the configuration for older builds/releases.
• Modify operation on the Virtual APN rule is not supported. User should delete the existing rule and add
new rule to achieve modify operation.
• If same option is provided multiple times in the same rule, then the value of later option is considered
for selection.
• Total number of Virtual APN rules added across all APNs is limited to 2048. This limitation exists in
non-CUPS architecture.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
540
 Cisco Confidential - Limited Release
User Plane Selection based on TAC Range
Configuring User Plane Selection based on TAC Range

Configuring User Plane Selection based on TAC Range

This section provides information about CLI commands available in support of this feature.

Configuring Tracking Area Code Range

Use the following CLI commands to configure APN for Tracking Area Code range in Control Plane node.
configure
context context_name
apn apn_name
virtual-apn preference preference apn apn_name tracking-area-code-range
tac_range
end
NOTES:
• tracking-area-code-range tac_range: Configures APN for Tracking Area Code range. The tac_range
is an integer value ranging from 0 to 65535.

Verifying the Tracking Area Code Range Configuration

Use the following CLI commands to verify if the feature is enabled and the range that is configured for
Tracking Area Code.
• show configuration apn apn_name
• show apn name apn_name

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
541
 Cisco Confidential - Limited Release
User Plane Selection based on TAC Range
Verifying the Tracking Area Code Range Configuration

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
542
 Cisco Confidential - Limited Release

CHAPTER 76
Virtual APN in CUPS
• Revision History, on page 543
• Feature Description, on page 543
• How It Works, on page 544
• Configuring Virtual APN in CUPS, on page 544

Revision History
Revision Details Release

In this release, support is added to enable location-based VAPN selection for 21.19
GGSN sessions.

First introduced. 21.8 (4/3/2018)

Feature Description
Access Point Name (APN) is a logical name referring to an external packet data network and/or to a specific
service that the subscriber wishes to connect to.
Virtual APNs allow differentiated services within a single APN.
The Virtual APN feature allows a carrier to use a single APN to configure differentiated services. The APN
that is supplied by the MME is evaluated by the P-GW along with multiple configurable parameters. Then,
the P-GW selects an APN configuration that is based on the supplied APN and those configurable parameters.
APN configuration controls all aspects of a session at the P-GW. Different policies imply different APNs.
However, after basic APN selection, internal reselection can occur based on the following parameters:
• Service name
• Subscriber type
• MCC-MNC of IMSI
• Domain name part of username (user@domain)
• S-GW Address

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
543
 Cisco Confidential - Limited Release
Virtual APN in CUPS
How It Works

A call received on a particular APN can be redirected to another APN through a Virtual APN, based on a
given criteria.
An APN received in the Create Session Request is called Gn APN, and the APN selected as part of a Virtual
APN selection is called Gi APN.
Currently, the GGSN, P-GW, SAEGW non-CUPS products support Virtual APN selection that is based on
the following modes:
• Local Configuration based
• Gx based
• RADIUS based
• Location based (for GGSN calls)

The P-GW/SAEGW deployed in CUPS mode also supports similar functionality to use the feature in network
deployments.

How It Works
The Virtual APN feature is supported as a forward compatible to CUPS architecture-based P-GW/SAEGW
nodes. Since the feature is being supported incrementally, following methods can be used to select Virtual
APN for CUPS-based gateway nodes:
• Local Configuration based
• Gx based
• Location based (for GGSN calls)

Limitations
Following are the known limitations and restrictions of this feature:
• User Plane Service node should be configured with identical APN configuration as configured on the
Control Plane Service node.
• RADIUS-based Virtual APN selection is not supported in this release.
• In CUPS deployment, a call cannot be initiated without a Gx service. Therefore, the Gx service reference
should be present in the APN configuration on Control Plane node.

Configuring Virtual APN in CUPS

Important The CLI commands available for non-CUPS Virtual APN feature is applicable in CUPS environment.

Following are sample configuration for:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
544
 Cisco Confidential - Limited Release
Virtual APN in CUPS
Configuring Virtual APN in CUPS

1. Control Plane node:

configure
context context_name
apn apn_name
pdp-type ip_address
bearer-control-mode mixed
selection-mode sent-by-ms
ims-auth-service service_name
exit
ip access-group acl_group_name in
ip access-group acl_group_name out
authentication pap preference chap preference allow-noauth
ip context-name context_name
virtual-apn preference preference apn apn_name
end

configure
context context_name
apn apn_name
pdp-type ipv4 ipv6
bearer-control-mode mixed
selection-mode sent-by-ms
ims-auth-service service_name
exit
ip access-group acl_group_name in
ip access-group acl_group_name out
authentication pap preference chap preference allow-noauth
ip context-name context_name
end
• For Gx-based Virtual APN selection:
configure
context context_name
ims-auth-service service_name
policy-control
diameter encode-supported-features virtual-apn
end
• For Location-based Virtual APN Selection for GGSN Calls:
configure
context context_name
apn apn_name
virtual-apn preference priority apn vapn_name
routing-area-code-range from start_value to end_value
end

2. User Plane node:

configure
context context_name
apn apn_name

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
545
 Cisco Confidential - Limited Release
Virtual APN in CUPS
Configuring Virtual APN in CUPS

ip context-name context_name
end

configure
context context_name
apn apn_name
ip context-name context_name
end

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
546
 Cisco Confidential - Limited Release

CHAPTER 77
VoLTE Support in CUPS
• Revision History, on page 547
• Feature Description, on page 547
• How It Works, on page 548
• Limitations, on page 550

Revision History
Revision Details Release

First introduced. 21.14.B0 (4/16/2019)

This feature is not fully qualified in this release.

Feature Description
VoLTE is now supported for P-GW (Pure-P) and SAE-GW (Collapsed) calls in the UPC CUPS Architecture.
With this release, the following functionalities are supported in this feature:
• SRVCC/CSFB support for VoLTE
• Support Suspend notification procedure
• Support Resume Notification procedure
• P-CSCF address selection.
• P-CSCF restoration.
• AF-Charging-ID support.
• Intelligent Graceful Shutdown support.
• PDN Reactivation support for IMS PDN
• Non-Standard QCI support

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
547
 Cisco Confidential - Limited Release
VoLTE Support in CUPS
How It Works

How It Works
The functioning of VoLTE in CUPS is implemented at a minimal level in this release.
• Suspend Notification for Pure-P and Collapsed calls
• Resume Notification for Pure-P and Collapsed calls

Call Flows VoLTE Support

The following section illustrates call flows that are in support of the VoLTE feature.

Handling Suspend Notifications

The following call flow illustrates Suspend Notifications for Pure-P and Collapsed calls.

On receiving a Suspend Notification message, the PGW-C requests the PGW-U to discard packets received
for the suspended PDN connection by setting the DROP flag in the Apply Action IE of the FARs of the
corresponding PFCP session.
As part of the suspend notification, the following actions are sent for uplink and downlink data:
• S-GW uplink FARS - Forward Action
• S-GW downlink FARS - Drop Action
• P-GW uplink FARS - Drop Action
• P-GW downlink FARS - Drop Action

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
548
 Cisco Confidential - Limited Release
VoLTE Support in CUPS
Handling Resume Notifications

The following conditions are also implemented:

• If SGW receives ULI/RAT/TZ Reporting MBR in Suspended state, all bearers are moved in to active
state and forwards MBR to PGW.
• If PGW receives ULI/RAT/TZ Reporting MBR in Suspended state, all bearers are moved in to active
state.
• On Receiving suspend notification Session idle timeout is stopped. If PGW receives Empty MBR in
Suspended state, all bearers are moved in to active state.

Handling Resume Notifications

The following call flow illustrates Resume Notifications for Pure-P and Collapsed calls.

On receiving the request to resume the PDN connection, the PGW-C re-allows the PGW-U to forward the
packets for the PDN connection by:
• setting the FORW flag in the Apply Action IE of the FARs of the corresponding PFCP session or
• setting the gate fields in the Gate Status IE of QERs to the value OPEN.

As part of the resume notification, the following actions are sent for uplink and downlink data:
• P-GW uplink FARS - Forward Action
• P-GW downlink FARS – Forward Action
• S-GW uplink FARS - Forward Action
• S-GW downlink FARS – Forward Action

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
549
 Cisco Confidential - Limited Release
VoLTE Support in CUPS
Limitations

Note On receiving Resume notifications, Session Idle timeout is restarted.

Limitations
The VoLTE support in CUPS has the following limitations:
• VoLTE Call Identification support.
• Session Recovery enhancement for VoLTE.
• VoLTE statistics
• Multimedia Priority Service support.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
550
 Cisco Confidential - Limited Release

CHAPTER 78
Volume Reporting over Gx
• Revision History, on page 551
• Feature Description, on page 551
• How it Works, on page 552
• Configuring VoGx Monitoring Key Range, on page 553
• Monitoring and Troubleshooting VoGx, on page 554

Revision History
Revision Details Release

With this release, monitoring key range is changed to 1-4000000000. 21.22

With this release, the following functionalities are implemented: 21.16 (10/25/2019)
• Monitoring key size and range.
• Control Plane handling for VoGx

First introduced. 21.13 (2/26/2019)

This feature is not fully qualified in this release.

Feature Description
The Volume Reporting over Gx (VoGx) feature provides PCRF the capability to make real-time decisions
based on the data usage by subscribers.
This feature is implemented using the existing non-CUPS architecture, for Control Plane. This implementation
is done by mapping the existing VoGx framework and the CUPS data structures such as FAR, PDR, URR
and so on.

Important Volume Reporting over Gx is applicable only for volume quota.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
551
 Cisco Confidential - Limited Release
Volume Reporting over Gx
How it Works

How it Works
The following steps explain how Volume Reporting over Gx works:
1. PCEF, after receiving the message from PCRF, parses the usage monitoring-related AVPs and sends the
information to IMSA.
2. IMSA updates the information to ECS.
3. After the ECS is updated with the usage monitoring information from PCRF, the PCEF (ECS) starts
tracking the data usage.
4. For session-level monitoring, the ECS maintains the amount of data usage.
5. For PCC rule monitoring, usage is monitored with the monitoring key as the unique identifier. Each node
maintains the usage information per monitoring key. When the data traffic is passed, the usage is checked
and reported against the usage threshold values.

Note In releases earlier than 21.22, the monitoring key value was in the range of 0-134217727.
In 21.22 and later releases, the monitoring key value is in the range of 1-4000000000.

6. The PCEF continues to track data usage after the threshold is reached and before a new threshold is
provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgment of
an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue
in the PCEF for that IP CAN session.

For additional information about this feature, refer the SAEGW Administration Guide.

Supported Standards
The Volume Reporting over Gx feature is based on the following standard: 3GPP TS 29.212 V9.5.0 (2010-06):
3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and
Charging Control over Gx reference point (Release 9).

Control Plane Handling for VoGx

URR Creation during Session Setup
• Sx Session establishment request is used as per the GxSPI framework.
• The Control Plane function sends the list of URRs in the Sx Session Establishment request, along with
their references in corresponding PDRs.

URR Processing in Detach Request

• The URR information will be sent by PGW-U as part of Sx Session Delete Response.
• PGW-C maps these URRs to the corresponding Monitoring-key Buckets and sends the CCR-T containing
Usage Report.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
552
 Cisco Confidential - Limited Release
Volume Reporting over Gx
User Plane Handling for VoGx

Sx Session Report Request

PGW-U sends the Usage Report for Volume Threshold. PGW-C maps the URRs to corresponding
Monitoring-key Buckets and generate the Gx CCR-U accordingly.

User Plane Handling for VoGx

Volume Threshold Breach
When data packets match a particular PDR and the PDR has associated URRs that have the measurement
method set as Volume, the uplink and downlink usage counters are incremented depending on the PDR source
interface type. Once a volume threshold is breached for a particular URR, an Sx Session Report Request
message is generated and sent with Usage Report Trigger set as Volume Threshold. All the usage counters
of the URRs that are reported is cleared once the message is generated and sent to Control Plane. However,
the existing threshold limit will be applicable for further transactions.

Limitations
The VoGx feature has the following limitations.
• Reporting of usage to PCRF during following event triggers are not supported in CUPS:
• Trigger
• PGW_TRACE_CONTROL (24)
• QOS_CHANGE_EXCEEDING_AUTHORIZATION (11)
• APN_AMBR_MODIFICATION_FAILURE (29)
• CHARGING_CORRELATION_EXCHANGE (28)
• OUT_OF_CREDIT (15)
• REALLOCATION_OF_CREDIT (16)
• UE_IP_ADDRESS_ALLOCATE (18)
• UE_IP_ADDRESS_RELEASE (19)
• APPLICATION_START (39)
• APPLICATION_STOP (40)
• REVALIDATION_TIMEOUT (17)

Configuring VoGx Monitoring Key Range

From Release 21.22 onwards, it is mandatory to define the monitoring-key urr-id-prefix entries for all the
monitoring keys configured locally in the PCEF as part static and predefined rules.
Use the following configurations to enable the monitoring key range.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
553
 Cisco Confidential - Limited Release
Volume Reporting over Gx
Monitoring and Troubleshooting VoGx

configure
active-charging service service_name
mon-key-urr-list list_name
monitoring-key value urr-id-prefix urr_id
end
NOTES:
• mon-key-urr-list list_name: Specifies the name of monitoring key list. list_name must be a string of
size 1-63.
• monitoring-key value: value must be an integer in the range of 1-4000000000.
• urr-id-prefix urr_id: urr_id must be an integer in the range of 1-8388607.
• Multiple monitoring key and URR ID combinations under the list name can be configured. The
recommended limit is 2500 entries.
• This CLI command can be configured in both Control Plane and User Plane. After configuring the CLI
command in Control Plane, it is mandatory to push the configuration to User Plane using PFD push
mechanism. For RCM, it is mandatory to configure require rcm-configmgr on User Plane before
configuring the CLIs. Both Control Plane and User Plane must be configured through CLI in RCM
configuration.
• You should configure only unique monitoring key and URR-ID combinations. These URR-IDs configured
through mon-key-urr-list should not coincide with the URR-IDs configured through urr-list. If such a
configuration is attempted, the CLI throws an error.
• If there is a run-time addition of this CLI at Control Plane, it is necessary to push the CLIs using PFD
push mechanism so that configurations can be updated at both ends. These configurations will apply next
call onwards or at the time of next URR creation.

Monitoring and Troubleshooting VoGx

This section provides information about the CLI commands available for monitoring and troubleshooting
VoGx in CUPS.

Show Commands and/or Outputs

show active-charging subsystem all debug-only
The output of this CLI command has been enhanced to include the following fields in support of VoGx feature
in CUPS.
• Total Mon-Key Urr Entries in list
• Total Mon-Key lookup success
• Total Mon-Key lookup failure

show user-plane-service monitoring-key-urr-id-list all

Use this CLI command to view all the monitoring keys that were pushed from Control Plane to User Plane.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
554
 Cisco Confidential - Limited Release

CHAPTER 79
VPN Manager Recovery Support
• Feature Summary and Revision History, on page 555
• Feature Description, on page 555

Feature Summary and Revision History

Revision History

Revision Details Release

First introduced. 21.14 (06/27/2019)

Feature Description
The VPN Manager Recovery Support feature enables the recovery of chunks after a VPN Manager (vpnmgr)
crash. To recover chunks after the crash, the chunks are stored and allocated to a particular VPN Manager in
the local VPN Manager.
When a pool VPN Manager crashes, it recovers the chunk from the local VPN Manager and all the used IPs
from all the Session Managers.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
555
 Cisco Confidential - Limited Release
VPN Manager Recovery Support
Feature Description

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
556
 Cisco Confidential - Limited Release

CHAPTER 80
VPP Support
Vector Packet Processing (VPPMOB) is a mobility-centric solution based on fd.io’s VPP, an open source
solution. It leverages fd.io development, particularly in the areas of IP forwarding, routing, and protocols.
• Revision History, on page 557
• Charging Support, on page 558
• Delay-Charging via Rulebase, on page 559
• Flow Idle-time Out, on page 559
• HTTP Support, on page 559
• IP Readdressing, on page 559
• LTE Handover, on page 560
• Next Hop, on page 560
• PDN Update, on page 560
• Policing, on page 561
• Pure-S Support, on page 562
• Response-based Charging via Service Schema, on page 562
• Response-based TRM via Service Schema, on page 562
• ToS Marking, on page 562
• Volume-based Offload, on page 563
• Supported Functionality, on page 563
• Limitations, on page 564
• Enabling Fast Path in User Plane Service, on page 564
• Enabling VPP on SI Platform, on page 564
• Monitoring and Troubleshooting VPP Fast Path, on page 565
• Support for VPP Configuration Parameters Override, on page 565

Revision History
Revision Details Release

Support for VPP Configuration Parameters Override is added. 21.14 (4/25/2019)

Support for Pure-S call data in VPP is added. This feature is not fully qualified 21.13 (2/26/2019)
in this release.
Limitation and Supported Functionality sections are updated.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
557
 Cisco Confidential - Limited Release
VPP Support
Charging Support

Revision Details Release

Limitation section has been modified for VPP crashlog support. 21.10 (11/9/2018)

VPP chrashlog support has been added. 21.10 (11/1/2018)

From this release, Policing support is added in VPP. 21.10 (8/28/2018)

With this release, support is added for LTE handover in VPP. 21.10 (8/10/2018)

With this release, support for the following has been added: 21.10 (7/31/2018)
• PDN Update
• Delay-Charging via Rulebase
• Response-based Charging via Service Schema
• Response-based TRM via Service Schema
• Volume-based Offload
• Charging Support

With this release, the associate fast-path service CLI command can be executed 21.9 (7/16/2018)
without enabling the debug mode commands. For configuration details, refer
Enabling Fast Path in User Plane Service section of this chapter.

With this release, support for the following has been added: 21.9 (6/29/2018)
• Flow Idle-time out
• Support for L7 - HTTP

First introduced. 21.9 (6/19/2018)

The following support are not fully qualified in this release:
• IP Readdressing
• URR Support
• Next Hop
• ToS Marking

Charging Support
Usage Reports are notified to the billing server on call deletion or volume/time threshold breach.
When a stream is created on the User Plane, flows – that involve Charging, are associated with charging-specific
operations that are set during the stream-creation. The charging counters for all flows – both offloaded and
non-offloaded, are maintained on the Fast Path.
During an overflow in the volume threshold, the Fast Path sends a notification with bucket counters (PUSH
mode) and in the case of time threshold hit, Applications reads charging counters from Fast Path (PULL

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
558
 Cisco Confidential - Limited Release
VPP Support
Delay-Charging via Rulebase

mode). The User Plane aggregates these counters with its respective URRs and triggers usage reports over
the Sx interface.

Important In this release, the URR support is there for both Volume and Time Threshold. Multiple SDF and one bearer
level URRs are supported.

Delay-Charging via Rulebase

The following flavors of delay-charging are supported:
• charge-to-application all-packets – All control packets (Handshake, midsession and tear-down) on a flow
are charged to the application packet matched charging-action.
• charge-to-application initial-packets – Handshake packets on a flow are charged to the application packet
matched charging-action.
• charge-to-application tear-down-packets – Tear-down packets on a flow are charged to the application
packet matched charging-action.
• charge-separate-from-application – All control packets are rule-matched and charged to the highest
priority rule.

In all the above scenarios, rule-matching is performed on the packet contents, and only the charging is delayed.

Important • charge-separate-from-application mid-session-packets are not supported. For an offloaded flow, they
continue to match the last matched rule.

Flow Idle-time Out

Configurable idle-time out is supported for the maximum duration of 24 hours. In earlier releases, support
was available only for specific set of values.

HTTP Support
Analysis of HTTP traffic and policy matching of such HTTP-based rules is supported in this release. Offloading
for HTTP flows is supported only for WebSocket, CONNECT method, or if content is present in
request/response.

IP Readdressing
IP readdressing for IPv4 and IPv6 is supported in this release.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
559
 Cisco Confidential - Limited Release
VPP Support
LTE Handover

IP readdressing is configurable using the charging-rule or post-processing rule associated with the
charging-action.
Streams are created on Fast Path for flows that match these rules along with the IP Readdressing operation
set. All these flows - both offloaded and non-offloaded – will have IPv4/IPv6 address set in the Fast path.

Important Currently, IP readdressing for list of servers is not supported.

LTE Handover
The following types of handovers are supported:
• S-GW Relocation for X2 based handovers (OI set to 1).
• S-GW Relocation for S1 based handovers (OI set to 0).
• eNodeB F-TEIDu Update.

For S-GW relocation, the following combinations are supported:

• P-GW anchored call.
• P-GW anchored call to Collapsed call.
• Collapsed call to P-GW anchored call.

Next Hop
Next hop address for IPv4 and IPv6 is supported in this release.
The Next-Hop address is configurable using the charging-rule or post-processing rule associated with the
charging-action.
Streams are created on Fast Path for flows that match these rules along with the Next Hop operation set. All
these flows - both offloaded and non-offloaded – will have Next Hop address set in the Fast path.

PDN Update
PDN Update procedures are supported with VPP in this release.
All flows are onloaded to SM-U whenever Rule Addition/Modify/Removal is received through any Gx
procedures. All the packets on these onloaded flows are then sent to SM-U. The flows are also onloaded when
transport level marking and charging parameters changes for the flow. These flows are again offloaded on
the packet for which rule-match changes, or Transaction Rule Matching (TRM) engages again.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
560
 Cisco Confidential - Limited Release
VPP Support
Policing

Policing
The policer configuration uses inputs from the session manager, these inputs are received either from PCRF
as AMBR or from flow-level QoS information. The values received from the PCRF is always accepted for
session level AMBR policing. But, the flow-level policing is prioritized, if available, and sequentially the
AMBR policing is applied. In other words, the policer engine applies the hierarchical policing - first the
flow-level/rule bandwidth limiting and then the session level bandwidth limiting.

Note AMBR modifications during session run-time through RAR or CCA-U is applicable.

The input values received from the session manager are pushed into a policer configuration and a policer
token bucket. For each direction - uplink or downlink, a new record is created for Policer configuration and
Policer token bucket.
The Policer configuration is the reference for the policer engine, and the policer token bucket is used for
calculation and restoration of values.
Currently, Policing is supported for AMBR received from PCRF and Rule-level QoS information for dynamic
rules. For static and predefined rules, bandwidth limiting is achieved by the bandwidth policy configuration.
Extended bit rates configured in bandwidth-policy configuration in Active Charging Service Configuration
mode on Control Plane is provided to the User Plane as part of the configuration push mechanism, and same
is applied for policing by User Plane. The following is an example configuration of bandwidth policy:
configure
active-charging service ACS
bandwidth-policy BWP

flow limit-for-bandwidth id 1 group-id 1

flow limit-for-bandwidth id 2 group-id 2

group-id 1 direction uplink peak-data-rate 256000 peak-burst-size 32000
violate-action discard
group-id 1 direction downlink peak-data-rate 256000 peak-burst-size 32000
violate-action discard
group-id 2 direction uplink peak-data-rate 128000 peak-burst-size 16000
violate-action discard
group-id 2 direction downlink peak-data-rate 56000 peak-burst-size 7000
violate-action discard
exit

Limitations
In this release, Policing has the following limitations:
• Modification of bandwidth-policy is not supported.
• Interaction with other features such as - ITC bandwidth limiting, token replenishment (both APN level
and ACL level) is not supported.
• Currently, policer-based statistics are not supported.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
561
 Cisco Confidential - Limited Release
VPP Support
Pure-S Support

Note As policer statistics are not yet supported, the operator can verify bandwidth
limiting using network performance monitoring tools.

Pure-S Support
Pure-S default bearer VPP integration is now supported in the CUPS Architecture. Earlier, Pure-S calls on
CUPS were supported using IFTASK. Now, Pure-S call data path also uses VPP.
As part of VPP integration for Pure-S calls, calls on SAEGW-UP will install one bearer stream (3 Tuple –
GTPU Service IP address, TEID, VRF id) per direction and also one TEP row per direction is created.
Supported Functionality:
Supported functionality for Pure-S includes:
• Most procedures for Collision between MME and Network Initiated scenarios (MBR/CBR/UBR/DBR).
• DBCmd and BRCmd commands.
• SAEGW-UP supports movement of IP transport from IPv4 to IPv6, or IPv6 to IPv4 during IDLE to
ACTIVE transition, and handover procedures on S1-u interface. Transport selected on S1-u at the time
of attach is also supported. For example, eNode handover from IPv4 eNodeB to IPv6 eNodeB.

Response-based Charging via Service Schema

HTTP Request is charged to the HTTP Response matched charging-action.

Response-based TRM via Service Schema

The Transaction Rule Matching (TRM) on uplink stream is engaged only after the HTTP response is received.

ToS Marking
Feature Description
ToS Marking for IPv4 and IPv6 is supported in this release.
The inner IP ToS marking address is configurable using the charging-rule or post-processing rule associated
with the charging-action. The outer IP ToS marking is performed using the QCI-DSCP marking table configured
on the control plane.
Streams are created on Fast Path for flows that match these rules along with the operations set. All these flows
- both offloaded and non-offloaded – will have IPv4/IPv6 ToS marking set in the Fast path.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
562
 Cisco Confidential - Limited Release
VPP Support
Volume-based Offload

Volume-based Offload
In case of HTTP protocol, the content in request/response (if present) gets offloaded to fastpath for each
transaction in a flow. The last packet of the content switches back the stream to passive state and the packet
reaches the Session Manager.

Supported Functionality
The following call flavors are supported in this release:
• Pure-P IPv4/IPv6 calls.
• Collapsed IPv4/IPv6 calls.
• Default bearer.
• Pure-S functionality.
• Dedicated bearer.
• Handovers.

The following functionalities are supported in this release:

• ToS marking of the payload packets (Charging action) and outer GTP-U packets (QCI/QoS mapping
table).
• Next hop feature (IPv4/IPv6).
• IP Readdressing feature (IPv4/IPv6).
• Post processing rules with action as discard.
• Post Processing rules with action as Next hop forwarding (IPv4/IPv6).
• Post Processing rules with action as ToS marking (UL, and DL).
• Post Processing rules with action as Readdressing (IPv4/IPv6).
• URR functionality (Gz only) - One SDF, and one bearer level URR.
• Only Gz charging is supported.
• Fragmentation and reassembly is supported in VPP.
• HTTP traffic policy match is supported. HTTP offload support is only for CONNECT and WebSocket
requests.
• This release has been validated to support up to 5000 flows across all applications per subscriber. Although
this limit is not imposed by the software, it is the recommended operating limit. Exceeding this limit
may lead to application failures and so, it is recommended that the following CLI be configured in the
Rulebase Configuration mode: flow limit-across-applications 5000.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
563
 Cisco Confidential - Limited Release
VPP Support
Limitations

Limitations
The following functionalities are not supported in this release:
• Gy and Rf are supported independently, however, they both cannot be enabled at the same time for the
same subscriber.
• Fast Path CLI can be disabled if it was previously enabled. However, User Plane must be reloaded.
• VPP crashlog support: Generation of crash records and mini-core files are supported. Generation of
full core files for VPP is not supported.

Enabling Fast Path in User Plane Service

Use the following CLI commands to enable Fast Path (VPP) in User Plane service.
configure
context context_name
user-plane-service service_name
associate fast-path service
end
NOTES:
• fast-path: Specifies the Fast Path related parameters.
• service: Specifies the Fast Path related configurations.

Enabling VPP on SI Platform

To launch VPP:
1. Log on to host machine, and create an ISO image that contains the file: staros_param.cfg
2. Create a file that has the line: FORWARDER_TYPE=vpp
3. Create an ISO file containing the staros_param.cfg file:
genisoimage -l -o ssi_vpp.iso -r vppiso/

If genisoimage is not installed, execute:

sudo apt-get install genisoimage

4. Stop the VM if it is running:

virsh destroy <vm_name>

5. If a disk is already attached to the VM that does not have VPP identified as the forwarder, then detach
the disk.
Run the dumpxml command on the VM to see if there is a disk attached.
To detach the disk, execute:

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
564
 Cisco Confidential - Limited Release
VPP Support
Monitoring and Troubleshooting VPP Fast Path

virsh detach-disk <vm_name> hdc –config

6. Attach the ISO file that contains the staros_param.cfg file:

virsh attach-disk <vm_name> <Path_of_ISO_FILE> hdc –type cdrom –config

Monitoring and Troubleshooting VPP Fast Path

To determine if the flows are offloaded, check for Fast Path statistics in the output of the following CLI
commands:
• show subscribers user-plane-only full all
• show user-plane-service all
• show user-plane-service statistics analyzer name ip
• show user-plane-service statistics analyzer name ipv6
• show user-plane-service statistics analyzer name tcp
• show user-plane-service statistics analyzer name udp
• show user-plane-service statistics analyzer name http

Support for VPP Configuration Parameters Override

To configure the VPP Configuration parameters, see the VPC-SI Administration Guide. These parameters can
be overriden. Ensure that you contact your Cisco account representative to assist in identifying the override
values.

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
565
 Cisco Confidential - Limited Release
VPP Support
Support for VPP Configuration Parameters Override

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
566
 Cisco Confidential - Limited Release

CHAPTER 81
VRF Support for CUPS
• Revision History, on page 567
• Feature Description, on page 567
• Configuring VRF, on page 568
• Monitoring and Troubleshooting, on page 571

Revision History
Revision Details Release

With this release, support is added for overlapping pools in same UP. 21.20.2

First introduced. 21.14 (4/15/2019)

The VRF Support for CUPS is not fully qualified in this release.

Feature Description
The VRF Support for CUPS feature enables association of IP pools with virtual routing and forwarding (VRF).
These IP pools are chunked like any pools. The chunks from this pool are allocated to the User Planes (UPs)
that are configured to use these pools. As in the existing deployment, VRF-associated pools in CUPS can
only be of type—STATIC or PRIVATE.
The chunks from the PRIVATE VRF pool are allocated when the UP comes for registration similar to the
normal private pools. The chunks from the STATIC VRF pool are allocated only when calls come up for that
chunk, similar to normal static pools.

Note VRF limit per UP is 205.

Overlapping Pools in Same UP

Overlapping pools share and use an IP range. Overlapping pools can either be of type STATIC or PRIVATE.
No public pools can be configured as overlapping pools. Each overlapping pool is part of different VRF

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
567
 Cisco Confidential - Limited Release
VRF Support for CUPS
Configuring VRF

(routing domain) and pool-group. Since an APN can use only one pool-group, overlapping pools are part of
different APN as well.
Without this functionality, overlapping pools can be configured at CP but chunks from two overlapping pools
can't be sent to same UP. That is, the UP can't handle chunks from two different overlapping pools. So, same
number of UPs and overlapping pools are required for sharing same IP range.
With this functionality, UP can handle chunks from two different overlapping pools. So, a single UP can
handle any number of overlapping pools sharing the same IP range.

Note Only VRF-based overlapping pools are supported in CUPS. Other flavors of overlapping pools, like NH-based,
VLAN-based, and so on, aren't supported in CUPS.

The functionality of overlapping pools in same UP includes:

• When a chunk from particular pool is installed on an UP, its corresponding vrf-name is sent along with
the chunk.
• The UPs are made VRF-aware of chunks and therefore, UPs install chunks on the corresponding VRFs
and the chunk database is populated under the VRFs.
• During call allocation, release, recovery, or any communication towards VPNMgr, the corresponding
SessMgr at UP includes vrf-id. This enables VPNMgr to pick the correct chunk for that IP under the
provided vrf-id for processing.

Configuring VRF
Follow these steps to implement VRF support for CUPS.
At Control Plane:
1. Associate the IP pool with VRF.
2. Create an APN to use this pool.
3. Associate UP with UP Group to ensure that the UP uses only the specific APN.
If there are overlapping pools, ensure that you create separate APNs for each one of the pools. Also, ensure
that different UPs use each of these APNs.

The following is a sample of the CP configuration:

context EPC2
apn mpls1.com
pdp-type ipv4 ipv6
bearer-control-mode mixed
selection-mode subscribed sent-by-ms chosen-by-sgsn
ims-auth-service iasGx
ip access-group css in
ip access-group css out
ip context-name isp
ip address pool name PRIVATE
ipv6 address prefix-pool PRIVATEV6
ipv6 access-group css6 in
ipv6 access-group css6 out

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
568
 Cisco Confidential - Limited Release
VRF Support for CUPS
Configuring VRF

cc-profile any prepaid-prohibited

active-charging rulebase cisco
user-plane-group mpls1
exit
apn mpls2.com
pdp-type ipv4 ipv6
bearer-control-mode mixed
selection-mode subscribed sent-by-ms chosen-by-sgsn
ims-auth-service iasGx
ip access-group css in
ip access-group css out
ip context-name isp
ip address pool name PRIVATE_1
ipv6 address prefix-pool PRIVATEV6_1
ipv6 access-group css6 in
ipv6 access-group css6 out
cc-profile any prepaid-prohibited
active-charging rulebase cisco
user-plane-group mpls2
exit

config
context isp
ip vrf mpls-vrf-1
ip vrf mpls-vrf-2
#exit

#exit
cups enable
ip pool PRIVATE 192.0.0.1 255.0.0.1 private 0 chunk-size 64 vrf mpls-vrf-1
ip pool PRIVATE_1 192.0.0.1 255.0.0.1 private 0 chunk-size 64 vrf mpls-vrf-2
ip pool STATIC 192.0.0.2 255.0.0.1 static vrf mpls-vrf-1
ipv6 pool PRIVATEV6 prefix 8001::aaaa/54 private 0 chunk-size 64 vrf mpls-vrf-1
ipv6 pool PRIVATEV6_1 prefix 8001::aaaa/54 private 0 chunk-size 64 vrf mpls-vrf-2
ipv6 pool v6pool2 prefix 2a02:2121:2c4::/46 static 0 vrf mpls-vrf-1
exit

user-plane-group mpls1
peer-node-id ipv4-address 192.0.0.2
#exit
user-plane-group mpls2
peer-node-id ipv4-address 192.0.0.3
#exit

At User Plane:
It's recommended to configure VRF in UP before chunk is pushed from CP. Else, it leads to the failure of
complete IP pool transaction (including chunks that don't belong to the VRF), and retry attempt by CP after
some time.
The following is a sample of the UP configurations:
User-Plane 1:
Config
context EPC2
sx-service sx
instance-type userplane
bind ipv4-address 192.0.0.2 ipv6-address bbbb:aaaa::4
exit
user-plane-service up
associate gtpu-service pgw-gtpu pgw-ingress
associate gtpu-service sgw-ingress-gtpu sgw-ingress
associate gtpu-service sgw-engress-gtpu sgw-egress
associate gtpu-service saegw-sxu cp-tunnel

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
569
 Cisco Confidential - Limited Release
VRF Support for CUPS
Configuring VRF

associate sx-service sx
associate fast-path service
associate control-plane-group g1
exit

context isp
ip vrf mpls-vrf-1
#exit
ip vrf mpls-vrf-2
#exit
apn mpls1.com
pdp-type ipv4 ipv6
bearer-control-mode mixed
selection-mode sent-by-ms
ip context-name isp
exit
exit
control-plane-group g1
peer-node-id ipv4-address 192.0.0.10
#exit
user-plane-group default

User-Plane 2:
Config
context EPC2
sx-service sx
instance-type userplane
bind ipv4-address 192.0.0.3 ipv6-address bbbb:aaaa::5
exit
user-plane-service up
associate gtpu-service pgw-gtpu pgw-ingress
associate gtpu-service sgw-ingress-gtpu sgw-ingress
associate gtpu-service sgw-engress-gtpu sgw-egress
associate gtpu-service saegw-sxu cp-tunnel
associate sx-service sx
associate fast-path service
associate control-plane-group g1
exit
exit

context isp
ip vrf mpls-vrf-1
#exit
ip vrf mpls-vrf-2
#exit
apn mpls2.com
pdp-type ipv4 ipv6
bearer-control-mode mixed
selection-mode sent-by-ms
ip context-name isp
exit
exit

control-plane-group g1
peer-node-id ipv4-address 192.0.0.10
#exit
user-plane-group default

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
570
 Cisco Confidential - Limited Release
VRF Support for CUPS
Monitoring and Troubleshooting

Monitoring and Troubleshooting

This section provides information regarding the CLI command available in support of monitoring and
troubleshooting the feature.

Show Command(s) and/or Outputs

This section provides information regarding show commands and/or their outputs in support of this feature.

show ip chunks
The output of this CLI command displays all the chunks in that context.
With Overlapping Pools in Same UP functionality, VRF option is introduced in the CLI, show ip chunks vrf
vrf_name, that displays only the chunks under that VRF.
• chunk-id
• chunk-size
• vrf-name
• start-addr
• end-addr
• used-addrs
• Peer Address

show ipv6 chunks

The output of this CLI command displays all the chunks in that context.
With Overlapping Pools in Same UP functionality, VRF option is introduced in the CLI, show ipv6 chunks
vrf vrf_name, that displays only the chunks under that VRF.
• chunk-id
• chunk-size
• vrf-name
• start-prefix
• end-prefix
• used-prefixes
• Peer Address

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
571
 Cisco Confidential - Limited Release
VRF Support for CUPS
show ipv6 chunks

Ultra Packet Core CUPS User Plane Administration Guide, Release 21.22
572