# A Next-Generation Core Network Architecture for Mobile Networks
## 3 A Novel Architecture
### SuperNode  
A new user (UE) subscribing for service to a cellular network operator must provide some information (e.g., personal information, billing, SIM data) which is added to the cellular operator's customer database and provisioned to an SN in the P2P network. How the provisioning mechanism and the SN selection process work are out of scope and reserved for future study. The operator's customer database is a distributed database and is hosted on the operator's private cloud. Such private cloud is separate from the cellular core network hosting infrastructure. Lastly, the customer database is also used to routinely store and backup UE's state.  
The Distributed Hash Table (DHT) used in the P2P core network can be any DHT characterized by the pair \(\{key:ID_{UE},val:DB_{URL}\}\). In particular, the \(key\) is an \(ID_{UE}=hash(IMSI)\), where the International Mobile Subscriber Identifier (IMSI) is a unique identifier assigned to a subscriber [19], and the corresponding \(value\) is a URL pointing to the UE's entry in the customer database.  
The number of active SNs can vary over time depending on various factors such as network load, security, and maintenance. Every time a new SN is added to the P2P network, the DHT re-organizes itself and the new SN gets a list of entries in the DHT containing pointers to the customer database. By having such information, the new SN can retrieve the current state of all the UEs it has to serve from that moment on.  
As summarized in Figure 6a, SNs in the P2P core network serve the following four different purposes:  
1. The SN is the UE's first point of attachment to the core network. As such, the SN is responsible for the UE authentication during the attachment phase. In particular, the SN behaves as a standard EPC and performs the standard authentication process. On a successful authentication, a default bearer is established between SN and UE. The attachment procedure is further discussed in Section 5.
2. After a successful authentication and attachment between UE and network, if the UE is not associated with a dedicated VCN, all basic signaling and \"light-weight\" tasks such as paging, SMS, push services (e.g., email notifications), voicemail, are handled by the SN the UE authenticated with.
3. An SN covers also the role of orchestrator for its UEs by creating and destroying VCNs and redirecting traffic accordingly. In particular, when a UE changes its state to \(active\) (e.g., by initiating or receiving a call, by browsing the Internet), its SN deploys a new VCN dedicated to that UE, updates the DHT accordingly (i.e., the UE is now reachable at its VCN) and informs the eNodeB (or eeNodeB) to redirect all traffic for that UE to the UE's VCN. On the other hand, once a UE  
Figure 5: Core network node protocol stack. (**a**) User Plane; (**b**) Control Plane.  
goes back to _idle_ state and stays in such state for a certain amount of time (see Section 11), the SN destroys the VM hosting the UE's VCN and triggers a \"redirect\" at the eNodeB. From that point on, all data and signaling for that UE are again sent to the SN.
4. The SN also acts as an SIP Registrar and re-direct server. In particular, after a successful attachment to the network and successful authentication with the SN, the UE performs an SIP registration with the SN. This registration allows the UE to be reachable for VoLTE service as per standard SIP operations. The re-direct server functionality, on the other hand, is used for redirecting the UE to the VCN and back to the SN, as described in Section 6.