Chapter 9. Traffic Profile and Dimensioning
vEPC and for that matter hardware based EPC solutions are typically based on use-case, call-model (ePDG, PGW, SGW/PGW or MME/SGW), number of subscribers being served. Typically, mobile operators share “call model” (exact call flow ladder diagrams) with NEPs so that the vEPC setup and configuration is tailored for that application.
vEPC consist of a rich set of features and capabilities ranging from normal 3gpp functions (SGW, PGW, MME etc) to Deep Packet Inspection (DPI), URL filtering/enrichment, Video/Content caching etc. Additionally for a connected-cars use case the same 3gpp functions may have different scaling requirements than when terminating 10 Million subscribers with smartphones. Good news is most vEPC VNFs are expected to support all these services and applications. They can be viewed as Swiss Army Knives as shown in Figure 29.

Figure 29: vEPC applications and their relationship to system resources
Based on the application, the dimensioning of vEPC could vary. IoT/M2M (Machine to Machine) is typically high in session count but low from throughput requirement. IoT devices could vary from small devices embedded in fields measuring nitrogen and moisture content to health care industry where it may be used to measure and ensure consistent temperature of medicine or organs being transported. These devices are typically not very chatty. They wake up, say what they need to say using tiny messages (could even be SMS) and then they go back to sleep. Due to the very high session count (imagine a future world where every device and appliance has an IPv6 address and is capable of communicating), the vEPC would have to be dimensioned for high memory. Billing applications take Call Data Records (CDRs) and creating and store billing entry constantly on disk. For this vEPC and underlying infrastructure (OpenStack and Hardware) will need to be designed and provisioned so that this constant Input/Output Operations (IOPs) don’t become an issue. Policy and control applications (PCRF) and Radius could be very chatty. Constant messaging occurs based on various activity of the subscribers. VoLTE (Voice over Long Term Evolution) is the voice application for 4G/LTE mobile networks. Voice typically implies a lot of small packets (We spec for 64 byte packets, however, in reality they could be more like 100 bytes and vary based on codec being used). In summary, there has to be some design and tuning done at the infrastructure level to accommodate different mobile services running on top of vEPC.
Table 2 summarizes the general requirements of vEPC. Some deployments could be smaller while others larger. While some KPIs such as session count, total bandwidth requirement could vary based on size of the deployment, others stay constant. Important KPIs to pay attention to are packet loss, jitter and latency.

Table 2: vEPC Traffic Profile (Source: OPNFV Summit 2016)
Dimensioning for GiLAN and IMS tracks that of vEPC or EPC subscribers if GiLAN is deployed with a non-virtualized EPC.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.