odes needed per core site are ready, the result of the GGSN dimensioning exercise will consist of simply taking the maximum of the values previously calculated. This will ensure that the most restrictive conditions are fulfilled. This process has been described generically for the number of GGSN nodes per core site, since the core site is the basic infrastructure entity in this context, but there should be no major difficulties in expanding this procedure for all foreseen core sites. It is worth noting that different GGSN nodes from different vendors may have additional limitations that are not described here, since only the principal aspects according to the most general types of inputs have been described here. The procedure should be to deal with those limitations in the same manner, considering the existing input situation and evaluating it against the network node maximum capability in terms of that given constraint. Dimensioning for Inter-GSN Traffic SGSN and GGSN are connected using the Gn interface. The amount of traffic that flows between SGSN and GGSN depends on the APN configuration. For example, a network has 2 GGSNs and 10 APNs. The first option is that the two GGSNs are configured in the n + 1 hot-standby redundancy mode. Therefore 100 % traffic flows through GGSN1 and, when it fails, the total traffic is routed via GGSN2. The second option is to configure them in a load sharing mode. In this mode, 5 APNs out of 10 may be configured on GGSN1 and 5 on GGSN2. The corresponding traffic is routed via respective GGSNs. If GGSN1 goes down, five APNs only will be affected. The third option would be to divide APNs among GGSNs based on traffic. It may be such that only three of the most popular APNs constitute 50 % of the traffic and are configured on GGSN1 while the remaining seven APNs, which constitute the remaining 50 % of the traffic, are routed through GGSN2. In a roaming scenario, roamers normally use the visitor SGSN and home GGSN SO that roaming traffic goes from the SGSN to the border gateway (BG) 