## 3 Function-Oriented Networking  
Related-works above SDN and NFV are all researches for network managers. OpenFlow is a technology which separates _date-plane_ from _control-plane_ so that a network manager can easily control the entire network. NFV is a technology that is actively deploying a network function such as Deep Packet Inspection (DPI), Firewall, even mobile communication equipment-_eNode B_, MobilityManagement Entity (MME), and Home Subscriber Service (HSS)--according to a network manager's requirement. Because such technologies (SDN, NFV) are designed entirely for network managers, some requirements of network users are hard to meet. For instance, Quality of Service (QoS) policies are decided/set by network managers. Thus it could be different from network users' requirements. In addition, if network users' requirements are reflected only through network managers, immediate policy change is impossible when needed. In this context, existing technologies have unsolvable problems when these are taken into the network managers' point of view. This paper proposes a novel user-centered network to solve the problems mentioned above: Function-Oriented Networking (FON). The network element supporting FON in a network is defined as FON Switch. Assume that the FON Switch can handle such a complex process including OpenFlow and classical functions (sort of Router, L2 Switch). In each FON Switch, FON is being processed as depicted in Figure 1. Multiple FON Functions can be operated. FON Function is defined as a network function which processes something not specific. It can run classic routing protocols such as RIP and OSPF. This aspect is similar with NFV. However, FON enables network users to change network policy; FON Function can be dynamically deployed/deactivated on FON Switch by network users. Figure 2 shows this scenario. Assume that: (1) a network user begins a new service. This new service needs the network policy corresponding to it; (2) this service requires End-to-End Delay to be the lowest. Then, by using FON system, network users can apply new policy that is matched to each Service's characteristic immediately by deploying New FON Function to each FON Switch. What follows is each _Enabling technology_ needed to realize such FON. The first one is OpenFlow. As a matter of fact, the network manager is not a critical point in the first article of OpenFlow. Rather, [PERSON]. [9] proposed a 5-Tuple by analyzing common functions need to realize QoS, Firewall for each vendor. It tried to develop a _network switch_ where various experimental policies can be applied by using the open-API OpenFlow. This paper focuses on the early OpenFlow philosophy that could be a useful tool to realize a policy for constructing a Programmable Network. The second one is a  
Figure 1: Function-Oriented Networking (FON) switch concept. Figure 2: FON scenario. Network slicing technology that can fulfill FON. If network users can totally control the network resources on the network, a serious security problem can be caused. This problem can be solved if a certain amount of resources is assigned through network slicing. To realize the scenario in Figure 2, FON must provide such technologies as below. (1) According to network user requirements, a new network function, FON _Function_, can be deployed/deleted on/from FON _Switch_; (2) FON should provide _APIs_ by making network resources abstractive so that FON _function_ can be easily implemented to apply new network policy. Especially, new policy is related directly to _Routing policy_. Because FON requests direct policy change, _On-demand_ method is more well-matched than the _Table-Driven_ method. In order to implement the FON proposed in this study to run on real network devices, and additionally to conduct experiments using ACO in FON, we built a physical device-based test bed. The test bed was tested by running a software image that implements the FON function on the Linux operating system on real Raspberry Pi Single Board Computer (SBC).