ng configuration in the network. The OpenFlow control plane connects the SGSNs, the standard OpenFlow switches, and the GGSN to the OpenFlow controller in the cloud. The physical implementation of the OpenFlow control plane may be as a completely separate physical network, or it may be a virtual network running on the same physical network as the data plane, implemented with a prioritized VLAN or with an MPLS label-switched path or even with a GRE or other IP tunnel. The OpenFlow control plane can, in principle, use the same physical control plane paths as the GTP-C and other mobile network signaling. The SGSN-Ds and the GGSN-Ds act as OpenFlow GTP-extended gateways, encapsulating and decapsulating packets using the OpenFlow GTP extensions. The NodeBs have no control plane entities in the cloud because the RAN signaling required between the RNC and the NodeB includes radio parameters, and not just IP routing parameters. Therefore, there is no OpenFlow control plane connection between the OpenFlow con- troller in the cloud and the NodeBs. The NodeBs can, however, act as OpenFlow GTP-extended gateways by implementing a local control to data plane connection using OpenFlow. This allows the packet switch- ing side of the NodeBs to utilize the same OpenFlow GTP switching extensions as the packet gateways. 5 SDN and NFV in 5G The operation of the PC cloud works as follows. The UE, NodeB, SGSN, and GGSN signal to the HLR, HSS, AuC, SMS-GMSC using the standard EPC protocols, to establish, modify, and delete GTP tunnels. This signaling triggers procedure calls with the OpenFlow controller to modify the routing in the EPC as requested. The Open- Flow controller configures the standard OpenFlow switches, the Openflow SGSN, and GGSN module with flow rules and actions to enable the routing requested by the control plane entities. Details of this configuration are described in the following section. Figure 5.15 illustrates how PC peering and differential routing for specialized service treatment are implemented. These flow rul