KYUNG_LAYOUT_Author Layout 9/4/15 3:36 PM Page 108
SOFTWARE DEFINED 5G NETWORKS FOR ANYTHING AS A SERVICE
Software Defined Service Migration through Legacy Service Integration into 4G Networks and Future Evolutions Yeunwoong Kyung, Tri M. Nguyen, Kiwon Hong, Jongkwan Park, and Jinwoo Park
ABSTRACT With the ongoing worldwide deployment of 4G networks and consequent drop of the utilization ratio of legacy networks, network operators need a cost-effective way to flexibly operate and manage networks. The obligatory continuation of legacy services in their respective legacy networks consistently incurs OPEX. In this situation, we argue that network operators can benefit from the recent advances in SDN and NFV. This article introduces a blueprint for designing a novel network architecture that integrates legacy network services into 4G networks through SDN/NFV’s software-based characteristics. In addition, our architecture reduces time to market for employing newly emerging services without mandating any changes in 4G infrastructures.
INTRODUCTION
Yeunwoong Kyung, Tri M. Nguyen, and Kiwon Hong are with Jinwoo Park Korea University. Jongkwan Park is with SK Telecom.
108
The explosive increase of mobile traffic along with the proliferation of smartphones, tablets, and laptops is fueling network evolution, from lower-generation network connectivity (second/third generation, 2G/3G) to higher-generation network connectivity (4G or Long-Term Evolution [LTE]/Evolved Packet Core [EPC]). With this transition, the number of 4G subscribers is continuously increasing, as 4G networks meet end-user demand with greater bandwidth. For example, Fig. 1 shows that the number of 4G subscribers already surpassed that of 2G and 3G subscribers in the months of September 2012 and July 2013, respectively, for SK Telecom subscribers in Korea [1]. Even in this situation, network operators continuously maintain and operate all the legacy networks (before 4G) because they are committed to providing services to satisfy subscribers’ quality of service (QoS) requirements for legacy networks. This means that operational expenditure (OPEX) for legacy networks is constantly incurred for operation, maintenance, power supply, real estate, and so on, although their utilization decreases.
0163-6804/15/$25.00 © 2015 IEEE
In addition, a current network has hardware/vendor-specific closed architecture with standardized interfaces. This feature leads to long time to market for deploying new services because operators have to wait for vendors to actually implement them after the standardization process, which is also time consuming. This means limited flexibility and openness. On these grounds, software defined networking (SDN) emerged, which is a new networking paradigm where the forwarding plane is decoupled from the control plane with a certain programmable interface between them. In SDN, network intelligence is logically centralized in the control plane, and the forwarding plane is abstracted from the control plane to orchestrate service delivery. SDN introduces the benefits of programmability, which enables network configuration or new services to be launched at a much faster rate than what is currently expected using hardware-centric networks. In addition, SDN has triggered significant interest in network functions virtualization (NFV). NFV is a new concept that decouples network functions from proprietary hardware appliances. Therefore, network functions run flexibly in software to accelerate service innovation and provisioning. The European Telecommunications Standards Institute (ETSI) is currently working on the requirements and architecture as well as technical challenges to produce normative specification of NFV [2]. Both SDN and NFV aim to advance a software-based approach for more manageable, agile, and innovative networks. With SDN/NFV’s characteristics, many researchers have proposed new architectures for future network design to handle the inefficiency of the current networks, as mentioned above. They have shown that current and new network services can be provided according to operator demand using novel SDN/NFV-based platforms. However, most existing proposals have assumed a fully SDN/NFV-based new network architecture [3, 4]. This means that conventional network infrastructures should be replaced by SDN/NFV-enabled infrastructures.
IEEE Communications Magazine • September 2015
KYUNG_LAYOUT.qxp_Author Layout 9/3/15 5:47 PM Page 109
To upgrade a network, a staged or transitional approach with the existing deployment should be considered rather than a green-field approach, as it is time consuming and expensive [5]. Therefore, we propose a new transitional approach called software defined transitional networking (SDTN). SDTN aims to provide legacy network services using the SDN/NFV paradigm on a current network. In SDTN, a 4G network is assumed to be the underlying current network because it is a highly enhanced mobile network in terms of network functionalities such as security, QoS, mobility, and interactions with other networks. As a result, other network service functions can be migrated or mapped to the 4G network service functions. In addition, a 4G network has been invested in substantially to accommodate a larger amount of traffic demand than that of 2G/3G. This means that it is required that network operators take full advantage of the 4G network. Therefore, in the SDTN architecture, legacy network service functions are implemented in the SDTN control plane and provided through the 4G network. Additionally, SDTN provides a suitable direction toward a fully SDN/NFVbased future network (e.g., 5G network). The rest of this article is organized as follows. After describing early efforts at staged approaches for SDN adoption, we present the core elements of SDTN. We then discuss its operational benefits and future directions.
RELATED WORKS Along with the considerable attention on SDN/NFV, lots of research works have been placed on SDN/NFV-based future network design [3, 4, 6, 7]. Although the necessity for compatibility [6] and an evolutionary approach [7] was mentioned, there are no works that provide a specific method of realizing transitional architecture based on existing networks. In addition, market leaders introduced their own SDN/NFV solutions [8, 9] to provide network services including 3G and 4G functions. Although it is conceptually clear that the network service functions can be virtualized in their solution and provided through the NFV infrastructure, a specific methodology is not explained for interacting with the forwarding plane to operate the network services and guarantee interoperability with existing network infrastructure. Compared to these approaches, there were early proposals for SDN deployment considering existing networks. They insisted that a more realistic and cost-effective strategy than building a new network from scratch was needed. There are three approaches to SDN adoption in an existing network infrastructure. The first is a dual stack approach [10], where all network nodes have both SDN and existing network interfaces (for normal layer 2 or 3 processing) to perform either SDN or normal processing. This approach necessitates a full deployment of network nodes capable of both SDN and normal operations. Therefore, it can become a complicated and costly solution. The second is a partial SDN approach called Panopticon [5]. Its authors
IEEE Communications Magazine • September 2015
20M 2G (CDMA) 16M
3G (WCDMA)
4G (LTE)
# of 4G subscribers > # of 3G subscribers
12M # of 4G subscribers > # of 2G subscribers 8M
4M
0 Nov. Jan. Mar. May. Jul. Sept. Nov. Jan. Mar. May. Jul. Sept. Nov. Jan. Mar. May Jul. 2011 2012 2012 2012 2012 2012 2012 2013 2013 2013 2013 2013 2013 2014 2014 2014 2014
Figure 1. SK Telecom mobile subscribers by month: split per access technology. showed that effective traffic steering could be performed with only some SDN nodes. However, network performance and operation can be affected by the number of SDN nodes and network size. In addition, the network is actually responsible for not only packet delivery but also providing network services. However, both aforementioned approaches have not revealed a solid way to provide network services, focusing only on SDN deployment for traffic engineering. On the other hand, in the Fabric approach [11], the authors proposed deploying SDN at the network access edge with a decoupled architecture, where the edge offers complex network services and the core only performs simple packet transport. In addition, separating the edge and core allows them to evolve independently. The authors focused on simplifying forwarding of core networks, but did not address network service provisioning and the problems of current networks mentioned in the previous section. The separation concept of the approach provides a hint as to the way to implement the SDN control plane for providing network services with an existing network infrastructure. Our focus is on SDTN design, which applies the SDN/NFV principles to integrate the legacy network services on the current 4G network. We detail the development of our prototype to validate the key elements of the architecture.
SOFTWARE-DEFINED TRANSITIONAL NETWORKS To address the challenges introduced in the previous sections, we set out to define SDTN architecture. The fundamental elements of the architecture are depicted in Fig. 2. Our architecture consists of three main components: access nodes, which are already deployed to support the variety of wireless networks such as evolved NodeB (eNodeB) for 4G; NodeB with radio network controller (RNC) for 3G (defined by the Third Generation Partnership Project, 3GPP, standards) and access point for Wi-Fi (defined by the IEEE 802.11 standards); edge switches (ESs) with an edge control plane (ECP), which
109
KYUNG_LAYOUT.qxp_Author Layout 9/3/15 5:47 PM Page 110
Although basic net-
Edge control plane 3G VNFs SGSN-C
work functions such as link discovery can
GGSN-C HLR
4G VNFs MME HSS
•••
2
be provided by the
PCRF
•••
Wi-Fi & new VNFs DHCP Security New VNF ••• • • •
Edge controller
controller itself, there is no sharp distinction between network functions provided by VNFs and the controller itself because it depends on the controller model and can be an implemen-
4G forwarding control plane SGW-C
1 3G access node
Wi-Fi access node
PGW-C
2 Ingress edge switch
EPC HW entities Transport network nodes 3
Egress edge switch
4G infrastructure
4G access node
Figure 2. Software defined transitional network architecture.
tation issue. Therefore, we assume that all network functions are implemented as VNFs.
110
serve as both ingress and egress elements for network service provisioning; and the 4G network, including the 4G forwarding control plane and infrastructure. The key property of SDTN design is the separation of ECP and ESs from the 4G network, applying the Fabric approach [11]. Through this separation, we limit most of the intelligence to ECP, keeping the 4G network unchanged. This means that ECP is in charge of providing rich network services, while the 4G network only performs packet transmission through the 4G infrastructure. Additionally, this separation allows for the independent evolution of the ECP and 4G network, focusing on the specifics of each role. Under this separation, incoming service requests are processed following three phases in Fig. 2. In the first phase, specific network functions are performed with the corresponding virtual network functions (VNFs) in the ECP. Then the ECP interacts with the 4G forwarding control plane and ESs to set the end-to-end data path. Finally, data is delivered. More specific service flow handling is described later in this article. Like any system, network architecture design is guided by interfaces. As shown in Fig. 3, we use five interface types to design our architecture: application-operator, operator-operator, operator-network, host-network, and packetswitch. The application-operator interface determines how services can be provisioned by the network operator and the operator-operator interface decides how different domains inform each other of their requirements. Other interfaces are defined in [11]. In addition, the application-operator, operator-operator, and operator-network interfaces are respectively mapped to the northbound, horizontal, and southbound interfaces, as defined in the general SDN framework [12]. In this context, we assume that SDTN utilizes already deployed access nodes as they are, because splitting the control functionality from the forwarding part of the access nodes is a much more complex and challenging task than for other core nodes [3], and modifying all
deployed access nodes is not practical because of cost constraints. Extending SDTN to the wireless parts will be one of our future works. We next investigate the details of each architectural component of SDTN.
SDTN NETWORK FUNCTIONS Although basic network functions such as link discovery can be provided by the controller itself, there is no sharp distinction between network functions provided by VNFs and the controller itself because it depends on the controller model and can be an implementation issue. Therefore, we assume that all network functions are implemented as VNFs. Figure 2 shows that legacy network functions, such as serving general packet radio service (GPRS) support node (SGSN), gateway GPRS support node (GGSN), home location register (HLR), and dynamic host configuration protocol (DHCP), are implemented as VNFs through NFV at the ECP, and perform the control processes previously done at the physical boxes. During each process, a set of VNFs are configured, provisioned, and chained by utilizing physical or virtual resources (i.e., orchestrated) to operate the specific network service on demand. In addition to the legacy network services, it is possible to provide new network services from ECP by virtue of SDN/NFV without the need for specialized physical boxes that only perform specific functions. In SDTN, pure 4G control functions such as the mobility management entity (MME), home subscriber server (HSS), and policy charging and rules function (PCRF) are also virtualized as VNFs at ECP. This means that only the control parts of serving gateway (SGW) physical box (SGW-C) and packet data network gateway (PGW) physical box (PGW-C) remain in the existing 4G control plane. There are two reasons for this approach. First, a network operator can manage all types of service information, such as user information, security, policy, and charging, simultaneously and centrally at the ECP. Furthermore, the network operator can flexibly control the MME and PCRF to communicate with
IEEE Communications Magazine • September 2015
KYUNG_LAYOUT.qxp_Author Layout 9/3/15 5:47 PM Page 111
the eNodeB, SGW-C, and PGW-C to prepare user plane processes utilizing this information. Second, SDTN can use existing 4G networks with minimal modification because the SGW-C and PGW-C are usually integrated into the EPC hardware entities within the 4G infrastructure. We call this existing 4G control plane that includes only SGW-C and PGW-C the 4G forwarding control plane. This means that the 4G infrastructure in Fig. 2 includes 4G transport network nodes and EPC hardware entities without control parts where the 4G traffic is delivered based on 4G-defined interfaces [13] and transmission policy [14]. VNFs run in a cloud environment and interact with the edge controller (EC) using the application-operator interface. Although VNFs are grouped logically for each service (e.g., 3G and 4G in Fig. 2), there can be many issues with the implementation of VNFs because instantiating them in a cloud environment has a tremendous effect on service performance. For example, grouping VNFs can reduce control signaling traffic by 70 percent from that of non-grouped VNFs [15]. Therefore, the implementation strategy for VNFs should be considered carefully with sufficient analysis of the interactions among VNFs when diverse network events occur.
EDGE CONTROLLER WITH EDGE SWITCHES As shown in Fig. 3, the EC supports four interfaces to interact with other elements: application-operator interface, operator-operator interface, operator-network interface 1, and operator-network interface 2. The applicationoperator interface is used to provide network services. The operator-operator interface facilitates communication with other ECs in the operator’s own network as well as different operators’ networks for scalability and policy consistency. As the network grows, the centralized controller causes a scalability issue. Therefore, operators with a very large area must consider an interface that interconnects with other controllers to handle this problem [12]. In addition, when a mobile user moves to another controller’s domain, a consistent service policy such as QoS should be guaranteed. To do this, policy-related information between controllers can be exchanged through the operator-operator interface. However, because information sharing between operators can be a very sensitive issue, the interface should be defined carefully with a contract between operators, and only essential information will be shared between them. Operator-network interface 1 is used to control ESs. ESs handle both the host-network and packet-switch interfaces, and carry out interface translation between them. In SDTN architecture, the host-network interface can be packet header fields according to each host’s network service protocol stack (e.g., 3G, 4G, or Internet) and the packet-switch interface can be expressed in the packet header that each 4G network node uses as an index for its forwarding table. For example, the GPRS Tunneling Protocol (GTP) header, User Datagram Protocol (UDP) header, and IP header fields can be used for the packetswitch interface because GTP tunneling is usually supported in 4G networks to transfer the data
IEEE Communications Magazine • September 2015
Network applications Application-operator interface Operator-operator interface Edge controllers Other controllers Operator-network interface 1 Host
Host-network interface
Edge switches
Operator-network interface 2 Packet-switch interface
4G networks
Figure 3. SDTN interfaces. traffic through eNodeB, SGW, and PGW. This means that ESs act as tunneling points like eNodeBs in 4G networks when legacy network service traffic goes through them. ESs are controlled by EC to make each entry in the forwarding table, as MME manages eNodeBs to set up tunnels in 4G networks. In this way, other network services can be supported in our architecture. Each entry is generated and updated using operator-network interface 1. For this interface, SDTN uses open or application programming interfaces (APIs) such as OpenFlow [10] that enable network software to be developed and upgraded much more easily than the current manual (re)configuration of hardware-centric machinery. The complexity lies in mapping the host-network interface to the packet-switch interface at ESs controlled by EC. There are two mechanisms for this process: protocol stack translation and encapsulation. Protocol stack translation provides the mapping by swapping the header of the incoming packets with the internal 4G protocol header such as the GTP header through the ingress ESs. The reverse process is performed at the egress ESs. Using encapsulation, packets crossing the ingress ESs are encapsulated by the 4G protocol headers, and then decapsulated at the egress ESs. The latter approach is more popular and preferable due to its lower complexity. In either method, all the incoming packets must be mapped to at least one entry at ESs. The entry may also include sophisticated functions such as filtering, isolation, or policy routing, as well as 4G protocol header fields. As SDTN aims for minimal modification of the existing 4G networks, EC supports 4Gdefined interfaces [13] for operator-network interface 2 to interact with existing 4G network nodes. For instance, S1-MME, S11, and Gx are utilized to manage eNodeB, SGW-C, and PGWC, respectively.
EXISTING 4G NETWORKS As explained above, the 4G forwarding control plane and infrastructure are included in 4G networks. Network nodes included in the infrastructure are controlled by the forwarding control plane to set the traffic path. After the mapping procedure at the ingress ESs, 4G network nodes can process the incoming packets with the packet-switch interface. As a result, 4G network nodes can deliver the packets while unaware of the original network service type of the packets. In addition, all the traffic is transferred fol-
111
KYUNG_LAYOUT.qxp_Author Layout 9/3/15 5:47 PM Page 112
The transmission pol-
3G host
NodeB
Edge switches
Edge controller
3G VNFs
4G VNFs
S/PGW
icy such as traffic RRC connection
classes and QoS parameters can differ among network ser-
Authentication, security, location management
Attach request
Phase 1
vices. Therefore, a
Attach accept with information
mapping between Include forwarding entry for mapping
4G transmission policy and other services’ transmission
Phase 2
Add forwarding entry
Tunnel & IP assignment
Attach accept Tunnel assignment & RRC reconfiguration
policies is required. Network operators Attach accept
should define this
Attach complete
mapping carefully to ensure the QoS
Attach accept
Create session request Create session response
Phase 3
3G service data flow
requirement for each service.
Figure 4. Information flow of 3G service in SDTN.
lowing a 4G-defined transmission policy such as the EPS bearer-based QoS policy. For example, incoming traffic into the ingress ES is assigned to a specific EPS bearer with bearer ID based on QoS requirements by using various QoS parameters defined in 3GPP standards [14]. Then bearer-based QoS control can be supported through the established bearer in 4G networks between ingress and egress ESs. In this way, traffic is transmitted applying the 4G-defined policy as if it is 4G service traffic. When the traffic goes out from 4G networks, QoS policy is converted to that of the original service at the egress ES. In this way, end-to-end QoS control can be provided. In fact, the transmission policy such as traffic classes and QoS parameters can differ among network services. Therefore, a mapping between 4G transmission policy and other services’ transmission policies is required. Network operators should define this mapping carefully to ensure the QoS requirement for each service.
USE CASE: FLOW HANDLING OF HETEROGENEOUS SERVICES Support of heterogeneous services, based on 4G, other legacy, or new protocols, can be achieved by interacting between the EC and the corresponding VNFs. For instance, when 3G service flow is processed, 3G VNFs such as SGSN-C and GGSN-C act as the original 3G functions, that is, SGSN and GGSN. In this case, the control plane process through 3G VNFs is always performed in advance of the user plane process in the 4G infrastructure. As introduced in Fig. 2, there are three phases for handling the 3G service flow, two control plane phases and a user plane phase. Figure 4 describes the abstracted information flow of these three phases for the initial attachment of a 3G host. In this figure, we assume that the NodeB and edge switches blocks
112
include NodeB and RNC, and ingress/egress ESs, respectively. First, after the radio resource control (RRC) connection is performed, the Attach Request message of the 3G host is delivered to the EC via the ingress ES because the ES does not have an entry matched to process the message. EC then carries it to the associated 3G VNFs. Subsequent to the host authentication and security setup between the host and 3G VNFs (we omit the detailed signaling flow of this step), the host location is updated, and the virtual session is established. In the 3G service control plane process, both SGSN-C and GGSN-C perform session management, and both SGSN-C and HLR exercise mobility management. In the second phase, all the information related to session and mobility management such as the host profile, policy, and location is stored centrally at the ECP and utilized to prepare the user plane process. To enable this, the EC handles S/PGW through MME and PCRF control using this information. In other words, via conventional 4G interfaces such as Gx and S11, the 4G VNFs control S/PGW using Session Request/ Response messages. Thanks to the interaction between the 4G forwarding control plane and ECP, the packet forwarding behavior of the 3G service flow such as GTP tunneling for EPS bearer service can be defined at the S/PGW. To complete the traffic path from the ingress to egress ESs, the EC controls ESs to include the forwarding entry for the mapping between 3G and 4G service flows. After the session establishment in the 4G networks is finished, the 3G VNFs send an Attach Accept message to the host via NodeB. This way, the radio access bearer of 3G service is established between the host and ingress ES via NodeB, and the EPS bearer of 4G service is established between the ingress and egress ESs for end-to-end QoS provision in user plane. Finally, 3G service traffic is transferred through the established bearer in the last phase.
IEEE Communications Magazine • September 2015
KYUNG_LAYOUT.qxp_Author Layout 9/3/15 5:47 PM Page 113
3G VNFs 4G VNFs SGSN-C GGSN-C HLR ••• SGW-C PGW-C MME
•••
Other & new VNFs 5G VNF New VNF
•••
•••
New interfaces between the infra-
SDN edge controller
structure and core controller as well as
Packet forwarding VNFs MPLS VPN GTP Other tunneling functions •••
Wi-Fi access node
3G access node
between the edge and core controller
SDN core controller
should be defined. While traditional
Ingress edge switch
4G access node 5G access node
SDN core infrastructure
Egress edge switch Edge/core control plane interface Control/dataplane interfaces
standardized interfaces are supported in SDTN, open interfaces or associated APIs will be utilized to foster network
Figure 5. SDTN’s future evolution.
service innovation in In the case of Wi-Fi service, it follows the same procedures as 3G service in SDTN. It is noted that Wi-Fi traffic is transmitted through ESs via either 4G infrastructure or the Internet based on the network operator’s policy.
OPERATOR BENEFITS AND FUTURE DIRECTION OF SDTN Along with the previously stated aspects, SDTN can provide new benefits that are not present in current networks. First, SDTN allows operators to reduce the OPEX of the core network for legacy network services because their core network equipment, such as physical boxes of GGSN and SGSN, the utilization of which gradually lessens with time, can be effectively discarded. OPEX reduction also occurs thanks to the lower maintenance, upgrade, real estate, and operational cost of a software-based approach. We expect that the OPEX could be further reduced when the majority of legacy services are virtualized on the SDTN architecture. Second, by separating the edge and 4G networks, SDTN allows operators to use already deployed 4G networks to provide legacy network services. This means that additional infrastructure capital expenditure (CAPEX) for the transport network is not required. In addition, SDTN can provide not only legacy services, but also new network services on the 4G infrastructure thanks to the benefits of SDN/NFV. Although additional CAPEX and OPEX of cloud infrastructure to provide VNFs are required, cost-efficient deployment and operation will be possible because cloud infrastructure can be less dependent on hardware appliances as well as physical locations, and optimally utilized in terms of resources and power even when the new services are introduced based on SDN/ NFV’s flexibility. Third, SDTN can be a transitional approach to the future network. As introduced earlier, many researchers and vendors believe that a fully SDN/NFV-based network is the appropriate direction of the future network. If a transi-
IEEE Communications Magazine • September 2015
tional approach is not considered, operators will have to discard all current network equipment and deploy a completely new SDN-enabled infrastructure. This is a time consuming process with large CAPEX. Instead, SDTN enables operators to prepare a fully SDN/NFV-based network with underlying current 4G networks as a staged approach. Additionally, SDTN architecture will be migrated to a fully SDN/NFV-based network. We expect that the fully SDN/NFV-based network will also have decoupled architecture between the edge and core parts, as shown in Fig. 5. Similar to SDTN, the edge part is responsible for complex service provisioning, whereas the core part performs packet forwarding. The difference with SDTN is the evolution of the underlying infrastructure and a core controller. Infrastructure consists of SDN-enabled network equipment and is controlled by an SDN core controller where VNFs related to packet forwarding such as tunneling functions are implemented. Therefore, flexible configuration of infrastructure for end-to-end traffic management is possible in a fully SDN/NFV-based network. In addition, new interfaces between the infrastructure and core controller as well as between the edge and core controller should be defined. While traditional standardized interfaces are supported in SDTN, open interfaces or associated APIs will be utilized to foster network service innovation in the future network.
the future network.
CONCLUSION This article introduces SDTN, an architecture and methodology for aiding network operators applying SDN/NFV in existing 4G networks. SDTN reaps the benefits of a software-based approach that not only integrates all the virtualized legacy network functions, but also increases the capability to roll out new network features. In addition, SDTN can evolve its network easily by updating or replacing network services on the edge control plane without mandating any changes in the existing 4G infrastructure. Therefore, the OPEX for the legacy networks and CAPEX for additional transport network infrastructure are not needed.
113
KYUNG_LAYOUT.qxp_Author Layout 9/3/15 5:47 PM Page 114
SDTN takes significant steps toward fully SDN/NFV-based future networks. We expect that SDTN will be migrated easily into future networks where all complex network services are implemented from the edge and forward-
Furthermore, SDTN takes significant steps toward fully SDN/NFV-based future networks. We expect that SDTN will be migrated easily into future networks where all complex network services are implemented from the edge and forwarding-related functions are provided in the core with SDNenabled infrastructure. In future work, SDTN will be validated to measure the practical benefits based on a virtualized network environment using OpenFlow-based components and real network events.
ACKNOWLEDGMENTS This work was supported by ICT R&D program of MSIP/IITP. [B0101-15-1272, Development of Device Collaborative Giga-Level Smart Cloudlet Technology].
ing-related functions
REFERENCES
are provided in the
[1] Ministry of Science, ICT and Future Planning, “Statistics on Telecom Services (2014),” July 2014. [2] ETSI, “Network Functions Virtualization (NFV); Infrastructure Overview,” ETSI Group Spec. NFV-INF 001 v. 1.1.1, Jan. 2015. [3] K. Pentikousis, Y. Wang, and W. Hu, “MobileFlow: Toward Software-Defined Mobile Networks,” IEEE Commun. Mag., vol. 51, no. 7, July 2013, pp. 44–53. [4] P. K. Agyapong et al., “Design Considerations for a 5G Network Architecture,” IEEE Commun. Mag., vol.52, no.11, Nov. 2014, pp. 65–75. [5] D. Levin et al., “Incremental SDN Deployment in Enterprise Networks,” Proc. ACM SIGCOMM, Aug. 2013, pp. 473–74. [6] R. Trivisonno et al., “SDN-Based 5G Mobile Networks: Architecture, Functions, Procedures and Backward Compatibility,” Trans. Emerging Telecommun. Technologies, vol. 26, no. 1, Jan. 2014, pp. 82–92. [7] C. J. Bernardos et al., “An Architecture for Software Defined Wireless Networking,” IEEE Wireless Commun., vol. 21, no. 3, June 2014, pp. 52–61. [8] Cisco, “Cisco Virtualized Packet Core,” C45-730492-01, Jan. 2015. [9] Alcatel Lucent, “Alcatel Lucent Virtualized EPC: Delivering on the Promise of NFV and SDN,” Alcatel-Lucent Application Note (NP2014014132EN), Feb. 2014. [10] N. McKeown et al., “OpenFlow: Enabling Innovation in Campus Networks,” Proc. ACM SIGCOMM Comp. Commun. Rev., Apr. 2008, pp. 69–74. [11] M. Casado et al., “Fabric: A Retrospective on Evolving SDN,” Proc. ACM HotSDN, Aug. 2012, pp. 85–90. [12] M. Jarschel et al., “Interfaces, Attributes, and Use Cases: A Compass for SDN,” IEEE Commun. Mag., vol. 52, no. 6, June 2014, pp. 210–17.
core with SDNenabled infrastructure.
114
[13] 3GPP, “Digital Cellular Telecommunications System; Universal Mobile Telecommunications System (UMTS); LTE; Network Architecture,” TS 23.002 v.12.6.0 Release 12 (2015-01), Jan. 2015. [14] 3GPP, “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2,” TS 136 300 v.12.3.0 (2014-09), Sept. 2014. [15] H. Hawilo et al., “NFV: State of the Art, Challenges and Implementation in Next Generation Mobile Networks (vEPC),” IEEE Network, vol. 28, no. 6, Nov. 2014, pp. 18–26.
BIOGRAPHIES YEUNWOONG KYUNG (
[email protected]) received his B.S. degree in electrical engineering from Korea University, Seoul, in 2011. He is currently in an M.S. and Ph.D. integrated course in the School of Electrical Engineering at Korea University. His research interests include flow-based mobility management in wireless networks and softwaredefined networking (SDN), especially SDN scalability and network service integration. TRI M. NGUYEN (
[email protected]) received his B.S. and M.S. degrees in computer science from Vietnam National University, Hanoi, in 2000 and 2006, respectively. He is currently working toward a Ph.D. degree in the School of Electrical Engineering at Korea University. His research interests include mobility management and resource management in wireless and broadband access networks. K IWON H ONG (
[email protected]) received his B.S. degree in electrical engineering from Korea University in 2011. He is currently in an M.S. and Ph.D. integrated course in the School of Electrical Engineering at Korea University. His research interests include the QoS management of optical IP networks considering service level agreements. J ONGKWAN P ARK (
[email protected]) is currently a leader of the Core Network Laboratory in the Network Technology R&D Center at SK Telecom. His research interests include software-defined networking and network functions virtualization for smart network deployment. In addition, he is focusing on service-centric networks to optimize network operation through flexible network traffic control based on the user profile, service types, and network context. JINWOO PARK (
[email protected]) received his B.S. in electronics engineering from Korea University in 1979 and his Ph.D. degree in electrical engineering from Virginia Tech in 1987. He is currently a professor with the School of Electrical Engineering at Korea University. His research interests are mobile service management in integrated wireless and wired networks, context-aware networking, content delivery networks, and software-defined networking.
IEEE Communications Magazine • September 2015
