# A Next-Generation Core Network Architecture for Mobile Networks
## 5 Basic Operations
### VoLTE Call Flow
#### 5.2.1 Scenario with eNodeBs  
Figure 13 shows a VoLTE call setup message flow when using a legacy eNodeB. Given that in our new architecture the core network is a P2P network, we use P2 PSIP as the signaling protocol for VoLTE calls. When UE1 wants to call UE2, UE1 sends an INVITE to its outbound SIP Proxy server that is, to SN1. (In the UE, outbound SIP Proxy Servers can be configured either statically or dynamically via DHCP or DNS, for example.) When SN1 receives the INVITE from UE1 it replies with a 100 TRYING to let UE1 know that it has received the INVITE and to stop re-transmissions. At the same time, SN1 deploys a VCN for UE1 and transfers UE1's state, including security context and SIP state, to VCN1. An EPS bearer update is also triggered by SN1 in order for UE1 to be able to send and receive packets from VCN1. We discuss the EPS bearer update process in Section 6. Once VCN1 is up and running, it queries the P2 PSIP overlay in order to find which VCN is responsible for UE2's Address of Record (An Address of Record is a unique SIP identifier in the form _user@domain_.) (AoR). If the VCN of UE2 (i.e., VCN2) is already up and running, the P2 PSIP overlay replies with the address of VCN2; if, on the other hand, VCN2 is not available, the P2 PSIP overlay replies with SN2's address. As per P2 PSIP standard, AppAttach messages are then exchanged so that the two nodes can directly talk to each other. A this point, assuming VCN2 is not yet available, VCN1 forwards the INVITE to SN2. When SN2 receives the INVITE, it deploys a VCN for UE2 (i.e., VCN2) and starts the EPS bearer update process. Simultaneously, SN2 replies to the INVITE with a 305 REDIRECT informing VCN1 that it has to use VCN2 as inbound SIP Proxy for UE2. VCN1 then sends the INVITE to VCN2 which forwards it to UE2. From this moment on, all SIP messages are routed directly from UE1 to VCN1 to VCN2 to UE2, and vice versa (see Figure 14). It is important to remark how P2 PSIP is used only for the discovery of the callee's SN and VCN while subsequent signaling and data do not leverage the P2P overlay but are sent via the respective VCNs.  
Figure 12: UE attach and SIP registration with eeNodeB.  
A few other considerations are in order. When SN1 deploys VCN1, it transfers SIP state to VCN1. Moreover, as explained in Section 4, VCN1's SIP Proxy server has the same private IP address of SN1's (i.e., SIP_IP_IN). Furthermore, an EPS bearer update is performed. This means that, at the application layer, UE1 is completely unaware that this change from SN1 to VCN1 has occurred, as it will continue using the same SIP Proxy server's IP address it was using before. The same thing, however, is not true for SN2 and VCN2. In particular, when VCN1 sends the INVITE to SN2, it sends it to SN2's public IP address (i.e., SIP_IP_OUT). This means that when VCN2 is up and running, SN2 will have to send a 305 REDIRECT in order for VCN1 to point to VCN2's public IP address (i.e., SIP_IP_OUT) instead of SN2's, given that these two are different. Therefore, in this case, transferring SIP state between SN2 and VCN2 is unnecessary, as the 305 REDIRECT triggers a re-transmission of the INVITE. UE2, on the other hand, is still unaware, at the application layer, of the change between SN2 and VCN2 because it continues to see the same SIP Proxy server's IP address (i.e., SIP_IP_IN).  
Figure 14: Data path after discovery phase.  
Figure 13: VoLTE call initiation with eNodeB.