not be dealt with at this stage, only node dimensioning. There is also a component of strategic planning in this case, since there could be a GGSN node in all the core sites, or only in one or two core sites. There could also be cases of GGSN nodes with dedicated access points placed in corporate premises, for instance for ISPs or corporate clients. The actual deployment plan will be based on a points of presence strategy and transmission costs for the ISP interconnections. As mentioned, the procedure is similar to the SGSN procedure. One difference in this case would be that, in the most general case, the physical interfaces of the GGSN will be the Ethernet for both Gn and Gi sides (possibly either a fast Ethernet or gigabit Ethernet, with a capacity 100 Mbps or 1 Gbps respectively). This means that in most cases the interface capacity will not be effectively a limiting factor, but perhaps the amount of interfaces in some cases. From that perspective, the most important limitations will be the GGSN throughput and maximum amount of simultaneous PDP contexts. As stated earlier, should the input provide further information in terms of subscribers' dynamic behaviour, then additional constraints, like the maximum number of PDP context activations, deactivations or modifications per second, could play a role as a limiting factor in concrete cases. Following the previous structure, the total amount of GGSN nodes required per core site will be calculated in two steps. Firstly, in terms of traffic flow, it is calculated by considering the total amount of Gn traffic that will be served in the given core site. This total amount of Gn traffic will be divided by the maximum throughput that a single GGSN can handle. This result, rounded up to the next integer, will be a rough estimation of the number of GGSNs needed for a given core site in a given year. One important aspect to consider in this case - and perhaps also in the SGSN dimensioning case - is the way to specify the traffic. Traditionally, for interface dimensioning,