ng and browsing applications, not SO much volume intensive, but rather demanding in terms of mobility management due to commuting at given commuting peak hours. A study of the OSS data indicates that the first SGSN is approaching its maximum nominal throughput during the busy hour for corporate users, somewhere around noon due to the heavy downloading activity of emails, documents, etc., while the signalling load offered for those users is rather low due to very limited mobility. In essence, a few users produce a heavy data volume, putting pressure on the throughput capability of the SGSN. The same OSS data also reveals that the second SGSN is actually serving more subscribers, whose busy hour is between 8 and 9 am, and later in the afternoon, around 6 pm, while commuting to and from their jobs, schools, etc. The traffic volumes created for those subscribers is not SO high, since they are mostly using applications such as instant messaging, multimedia messaging and browsing news. In this case, there are many more users, eventually close to the maximum nominal value for the simultaneous Core Network Planning and Optimisation attached subscribers, while the throughput limits are far from the traffic volumes currently measured. Additionally, some reports also indicate that the signalling load is rather high, due to the amount of routing area updates caused by the commuters in the trains. In this case, there are many more users, eventually close to the maximum nominal value for the simultaneous attached subscribers and, in addition, some early warnings of increasing signalling load. Meanwhile, the throughput limits are far from the traffic volumes currently measured. Based on the observations described above, an optimisation activity can be launched, with the purpose of redistributing the eight RNCs between the two existing SGSNs, with a target of distributing the current load offered by those RNCs more evenly with regard to three criteria: The number of subscribers The throughput offered per subscriber Mobility mana