Cisco Cisco Packet Data Gateway (PDG)

 



 

Currently, the “File” command that controls the file naming can be modified to include/exclude the rulebase and 

format name in the filename. 



 

By including the rulename and format name, customer can know what EDRs are present in each file just by 

looking at the filename. 



 

If either rulebase or format name was not added to the filename, then customer has to open the file to determine 

type of information stored in each file. 

New Behavior:  Customers have started increasing the number of rulebases exponentially. As a result, CDRMOD has 
to open too many files and this results in inefficient file operation. The system ends up having too many small files, 
which leads to file transfer delay. 

The solution is to bundle records with similar fields (header) into a single file so that there are a few larger files rather 
than too many small files. This fix helps with this solution. 

Customer Impact:  There should not be any impact on customer backend record processing due to this change. 



 

If currently configured to include “rulebase” and “format,” then behavior is the same. 



 

If excluding “rulebase” and/or “format” currently, then backend record processing tool should know how to 

process the records in each file without looking into the filename. 

Going forward, customers will have the option to bundle different SIMILAR records into single file and thereby can 
increase the number of rule-base. 

This is relevant only for a GnGp setup where associated GGSN and P-GW services exist and WiFi PDN attachments are 
expected on P-GW.A WiFi PDN connection for Subscriber can now co-exist with a Gn GGSN (3G) PDN connection 
for the same EBI and NSAPI value. 

Previous Behavior:  When a new Gn GGSN (2G/3G) call comes in, the existing WiFi PDN connection using matching 
EBI with the NSAPI of existing PDN would get dropped. 

Similarly, when a new ePDG (WiFi) call comes in, the old Gn GGSN call (3G) would get dropped when EBI of WiFi 
PDN request matches with the NSAPI of new PDP Context request from Gn GGSN. 

New Behavior:  An ePDG PDN (WiFi) can now co-exist with a Gn GGSN (3G) PDN with matching EBI and NSAPI. 

Customer Impact:  It is expected that in the above condition, peers will also continue to maintain session and both 
PDN connections would be valid unless one of the PDN can be considered as stale PDN on GW; the stale PDN would 
eventually get cleared with idle timer functionality if there is no traffic flowing through it.