WO2016148527A1 - 이동 통신 시스템에서 패킷 생성 방법 및 장치 - Google Patents

이동 통신 시스템에서 패킷 생성 방법 및 장치 Download PDF

Info

Publication number
WO2016148527A1
WO2016148527A1 PCT/KR2016/002714 KR2016002714W WO2016148527A1 WO 2016148527 A1 WO2016148527 A1 WO 2016148527A1 KR 2016002714 W KR2016002714 W KR 2016002714W WO 2016148527 A1 WO2016148527 A1 WO 2016148527A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
fon
packet
network
node
Prior art date
Application number
PCT/KR2016/002714
Other languages
English (en)
French (fr)
Inventor
임한나
이성원
김기정
박중신
Original Assignee
삼성전자 주식회사
경희대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사, 경희대학교 산학협력단 filed Critical 삼성전자 주식회사
Priority to US15/558,989 priority Critical patent/US10645613B2/en
Publication of WO2016148527A1 publication Critical patent/WO2016148527A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166—IP fragmentation; TCP segmentation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems

Definitions

  • the present invention relates to a method and apparatus for generating a packet in a mobile communication system.
  • a 5G communication system or a pre-5G communication system is called a after 4G network communication system or a post LTE system.
  • 5G communication systems are being considered for implementation in the ultra-high frequency (mmWave) band (eg, such as the 60 Gigabit (60 GHz) band).
  • mmWave ultra-high frequency
  • FD-MIMO massive array multiple input / output
  • FD-MIMO full dimensional MIMO
  • 5G communication system has evolved small cells, advanced small cells, cloud radio access network (cloud RAN), ultra-dense network , Device to device communication (D2D), wireless backhaul, moving network, cooperative communication, coordinated multi-points, and received interference cancellation
  • cloud RAN cloud radio access network
  • D2D Device to device communication
  • wireless backhaul moving network
  • cooperative communication coordinated multi-points
  • received interference cancellation The development of such technology is being done.
  • FQAM hybrid FSK and QAM modulation
  • SWSC sliding window superposition coding
  • ACM advanced coding modulation
  • FBMC advanced access bank filter bank multi carrier
  • NOMA NOMA Non-orthogonal multiple access and sparse code multiple access
  • IP Internet Protocol networking
  • IP networking is a technology that is making rapid progress thanks to the rapid development of Internet technology.
  • IP networking each user and a specific server operate with a fixed address, that is, an IP address, and routing is performed based on the address.
  • Routers support IP networking, enabling end-to-end communication in a global network.
  • IP address in IP networking is used only as a unique identifier of a terminal in a global network, it supports only simple packet transmission and has difficulty in supporting multimedia and interchange communication services.
  • IP address alone cannot recognize the service.
  • routers combine the control plane and the data plane into one device, and each router operates independently with different control plane information, it is difficult to introduce a new networking protocol.
  • routers use fully distributed routing algorithms and protocols, a network operator cannot directly define a routing policy.
  • User and Internet Service Provider also do not participate in routing policy, there is a problem that can not check the static / dynamic information of the network.
  • the present invention provides a method and apparatus for generating a packet in a mobile communication system.
  • the present invention provides a method and apparatus for directly applying a function desired by a user / internet service provider to a network.
  • a method of generating a packet in a device in a mobile communication system comprising: generating a function-based packet; And transmitting the packet to a target node, wherein the packet does not include an internet protocol (IP) address.
  • IP internet protocol
  • the present invention can apply a function desired by a user / internet service provider directly to a network.
  • 1 is a diagram of a router structure supporting a packet transmission scheme of a router
  • FIG. 2 is a diagram illustrating an IP packet structure supporting a packet transmission scheme of a router
  • FIG. 3 is a diagram of a router structure supporting an open flow packet transmission scheme
  • FIG. 4 is a flowchart illustrating an IP packet processing procedure in a router supporting an open flow packet transmission scheme
  • FIG. 5 is a flowchart illustrating a process of generating / transmitting and receiving an IP packet of an IP application
  • FIG. 6 is an exemplary diagram of socket control related program code of an IP-based application described with reference to FIG. 5;
  • FIG. 7 is a flowchart illustrating a TCP / UDP segment transmission process in a TCP / UDP layer
  • FIG. 8 is a flowchart illustrating an IP packet transmission process in an IP layer
  • FIG. 9 is a flowchart illustrating a process of receiving an IP packet in an IP layer
  • FIG. 10 is a flowchart illustrating a TCP / UDP segment receiving process in the TCP / UDP Layer
  • FIG. 11 is a structural diagram of a mobile communication system for packet generation according to an embodiment of the present invention.
  • FIG. 15 is a detailed structural diagram of a FON device according to an embodiment of the present invention.
  • FIG. 16 is another detailed structural diagram of a FON device according to an embodiment of the present invention.
  • FIG. 17 is a flowchart illustrating a smart packet generation / transmission and reception process in a FON application
  • FIG. 18 is an exemplary diagram of socket control related program code of a FON based application in a FON device
  • 19 is a flowchart illustrating a smart packet transmission process in a FON layer
  • 20 is a structural diagram of a function table stored in a DB of a FON device
  • 21 is a flowchart illustrating a smart packet reception process in a FON layer
  • 22 is a flowchart showing a smart packet reception process in a FON node
  • Fig. 23 is a view and a structure of a function table stored in a DB of a FON node
  • 24 is a format showing an example of a function usage information report message
  • 26 is a structure diagram and an example of a function distribution message according to an embodiment of the present invention.
  • FIG. 27 is a structure diagram and an example of a function deletion message according to an embodiment of the present invention.
  • 29 is a structural diagram of an accounting table according to an embodiment of the present invention.
  • FIG. 30 is a scenario illustrating an example of data communication between a user terminal and a sensor in a typical 4G / 5G mobile communication network
  • FIG. 31 is a scenario illustrating a data communication process between a user terminal and a sensor when the transmission scenario of FIG. 30 is applied to the present invention
  • 32 is a diagram illustrating general end-to-end packet transmission path information collection
  • 35 is a diagram illustrating a conventional 3rd-Party web service or media service acceleration
  • 36 is a diagram illustrating acceleration of 3rd-Party web service or media service according to an embodiment of the present invention.
  • An embodiment of the present invention is a Long-Term Evolution (LTE) mobile communication system and a Long-Term Evolution-Advanced (LTE-A).
  • LTE-A ') mobile communication system high speed downlink packet access (HSDPA, hereinafter referred to as'HSDPA') mobile communication system, high speed uplink packet access (high speed) High rate packet data on will be referred to as 3GPP2, hereinafter '3GPP2') (: uplink packet access: HSUPA, hereinafter will be referred to as 'HSUPA') mobile communication system and a third-generation project partnership 2 (3 rd generation project partnership 2 high rate packet data (HRPD), hereinafter referred to as HRPD), and a 3GPP wideband code division multiple access (WCDMA) mobile communication system.
  • HSDPA high speed downlink packet access
  • HRPD third-generation project partnership 2
  • HRPD third-generation project partnership 2
  • WCDMA wideband code division multiple access
  • CDMA Code min of 3GPP2 Multiple Access
  • EPS evolved packet systems
  • Mobile IP mobile Internet Protocol
  • Packet routing and forwarding technology a packet transmission method of a router in which a control plane and a data plane are integrated, and an open flow in which the control plane and the data plane are separated. There is a packet transmission method of.
  • 1 is a diagram of a router structure supporting a packet transmission scheme of a router.
  • the router 100 includes a routing processor 110, a forwarding processor 120, and a database (DB) 130 to provide routing and forwarding for IP packets.
  • DB database
  • the routing processor 110 generates a routing table 140 that includes physical port information (hereinafter referred to as "port information") according to the destination IP address.
  • port information physical port information
  • the DB 130 stores the generated routing table.
  • the forwarding processor 120 When the forwarding processor 120 receives the IP packet, the forwarding processor 120 refers to the routing table 140 stored in the DB 130 to identify a physical port corresponding to the destination IP address of the IP packet. If the destination IP address of the received packet exists in the routing table, the forwarding processor 120 forwards to the physical port corresponding to the destination IP address. However, if the information about the destination IP address of the received packet does not exist in the routing table, the forwarding processor 120 forwards to the default physical port.
  • FIG. 2 is a diagram illustrating an IP packet structure supporting a packet transmission scheme of a router.
  • the IP packet 200 of FIG. 2 includes a trailer 205, a payload 207, a source L3 / L4 address field 210, a destination L3 / L4 address field 220, a source MAC header ( 230, destination MAC header 240.
  • the source L3 / L4 address field 210, the destination L3 / L4 address field 220 include an IPv4 / IPv6 address (hereinafter referred to as an “IP address”) 250, a TCP / UDP port number 260, and the like. do.
  • FIG. 3 is a diagram of a router structure supporting an open flow packet transmission scheme.
  • the router of FIG. 3 is separated from the routing processor 310 and the forwarding processor 330.
  • the open flow control unit 300 includes a routing processor 310 and a DB 312.
  • the open flow switch 320 includes a forwarding processor 330 and a DB 332.
  • the routing processor 310 generates a routing table.
  • DB 312 stores the generated routing table.
  • the open flow control unit 300 transmits the packet control information for controlling the packet to the open flow switch 320 using the open flow protocol 315.
  • the open flow switch 320 receiving the packet control information stores the packet control information in the rule-action table 334.
  • FIG. 4 is a flowchart illustrating a process of processing an IP packet in a router supporting an open flow packet transmission method.
  • the forwarding processor 330 described below may be understood as a controller or a processor that performs the operation of FIG. 4.
  • the forwarding processor 330 receives an IP packet in step 401. Thereafter, the forwarding processor 330 checks IP packet header information (hereinafter, referred to as an "IP packet header") of the IP packet received in step 403. The forwarding processor 330 extracts header information such as a destination / source MAC address, a destination / source IP address, and a destination / source TCP port number through the IP packet header.
  • IP packet header IP packet header information
  • the forwarding processor 330 checks whether the header information extracted in step 405 matches the rule information written in the rule-action table 334. If the extracted header information and the Rule-Action table 334 do not match, the open flow controller 300 forwards the received packet to the forwarding processor 330 and receives the packet according to the decision of the open flow controller 300. One packet can be forwarded or dropped to a particular physical port.
  • the forwarding processor 330 checks and / or determines the Action type of the Rule-Action table 334 in step 407.
  • the forwarding processor 330 performs flow control and forwarding according to the action information (or type). If the Action type is "drop”, the forwarding processor 330 drops the packet in step 409.
  • the forwarding processor 330 forwards the packet received to the single or multiple physical ports in step 411.
  • the forwarding processor 330 forwards the packet received to the open flow controller 300 to report in step 413.
  • the forwarding processor 330 proceeds to step 415, in step 409, As in step 411 and step 413, statistics for the completed function are updated.
  • FIG. 5 is a flowchart illustrating an IP packet generation / transmission and reception process of an IP application.
  • FIG. 5 The operation of FIG. 5 is performed in a terminal supporting the TCP / IP protocol.
  • the IP application creates a socket for IP communication by calling the socket () function in step 501.
  • the IP application attempts to connect to the remote host by calling a terminal connection function (connection () function) in step 503.
  • step 505 the IP application determines whether to transmit or receive data to the remote host.
  • the IP application calls the write () function in step 507 to request data transmission to the TCP / UDP layer. As in step 511, if there is no more data to transmit, the IP application terminates the established connection with the remote host by calling the close () function in step 513.
  • the IP application When receiving data from the remote host, the IP application calls the read () function in step 509 to request the TCP / UDP layer to extract and receive data of the IP application from the IP packet received from the remote host. Thereafter, as in step 511, if the user no longer wants to receive data or there is no more data to receive, the IP application terminates the established connection with the remote host by calling the close () function in step 513.
  • FIG. 6 illustrates an example of a socket control related program code of an IP-based application described with reference to FIG. 5.
  • Reference numeral 610 denotes an example of the socket () function in step 501 of FIG.
  • Reference numeral 620 denotes an example of a connection function in step 503 of FIG. 5.
  • FIG. 7 is a flowchart illustrating a TCP / UDP segment transmission process in a TCP / UDP layer.
  • the TCP / UDP Layer receives data from the IP application in step 701.
  • the TCP / UDP Layer creates a TCP / UDP segment by adding a TCP / UDP header to the data received in step 703.
  • the TCP / UDP layer delivers the segment created in step 705 to the IP layer (Layer 3).
  • FIG. 8 is a flowchart illustrating an IP packet transmission process in an IP layer.
  • the IP layer receives a TCP / UDP segment from the TCP / UDP layer.
  • the IP layer adds an IP header to the TCP / UDP segment to generate an IP packet.
  • the IP layer transmits the IP packet generated in step 805 to Layer 2 such as Wi-Fi and Long Term Evolution (LTE).
  • Layer 2 such as Wi-Fi and Long Term Evolution (LTE).
  • FIG. 9 is a flowchart illustrating a process of receiving an IP packet in an IP layer.
  • the IP layer (Layer 3) receives the IP packet of the remote host from Layer 2 such as Wi-Fi and LTE in step 901. That is, the IP layer receives that the IP packet is extracted by removing the frame header from the L2 frame from Layer 2. After receiving the IP packet, the IP layer extracts the TCP / UDP segment by removing the IP header in step 903 and delivers the segment to the TCP / UDP layer in step 905.
  • FIG. 10 is a flowchart illustrating a TCP / UDP segment receiving process in the TCP / UDP layer.
  • the TCP / UDP layer receives the TCP / UDP segment from the IP layer in step 1001. After receiving the TCP / UDP segment from the IP layer, the TCP / UDP layer extracts the application data by removing the TCP / UDP header in step 1003. The TCP / UDP Layer delivers application data to the IP application in step 1005.
  • Routers support IP networking, enabling end-to-end communication in a global network.
  • IP address in IP networking is used only as a unique identifier of a terminal in a global network, it supports only simple packet transmission and has difficulty in supporting multimedia and interchange communication services.
  • IP address alone cannot recognize the service.
  • routers combine the control plane and the data plane into one device, and each router operates independently with different control plane information, it is difficult to introduce a new networking protocol. Because routers use fully distributed routing algorithms and protocols, network operators cannot directly define routing policies. User and Internet Service Provider are not involved in routing policy, nor can they check static / dynamic information of network.
  • a technology that complements the problems of the conventional router technology is open flow, which is an implementation of Software Defined Networking (SDN) technology.
  • Routers have a fully distributed control plane structure, while open flow has a centralized control plane structure.
  • the router forwards the packet by identifying the physical port to be forwarded using only the destination IP address, while open flow uses the packet using various field information such as the destination / source MAC address, the destination / source IP address, and the destination / source TCP port number.
  • the controller can also perform packet forwarding and packet discarding.
  • the technical characteristics of the open flow allows the open flow controller to programmatically control the flow of the packet by issuing a packet control command to the open flow switches controlled by the open flow controller.
  • the packet is forwarded using various field information such as the destination / source MAC address, the destination / source IP address, and the destination / source TCP port number, detailed flow control is possible.
  • open flow provides finer and more programmable flow control than routers, but is limited to forwarding and flow control for IP packets. So open flow, like routers, cannot provide new network layers and protocols other than the IP protocol. Specifically, it is not possible to provide network programmability (Network Programmability) that can create and perform network functions by the network operator / internet service provider / user. In addition, open flow can only be controlled by a network operator, and flow control by an Internet service provider and a user is not possible. Open flow only increments the counter each time a packet corresponding to the flow written in the Rule-Action table is processed, and cannot collect static and dynamic state information of the network.
  • Network Programmability Network Programmability
  • Open flow only increments the counter each time a packet corresponding to the flow written in the Rule-Action table is processed, and cannot collect static and dynamic state information of the network.
  • open flow switches require complex deep packet inspection (DPI) to control multiple flows.
  • DPI deep packet inspection
  • the open flow switch receives a large number of packet flows that do not exist in the Rule-Action table, performance degradation occurs.
  • the open flow switch receives a plurality of packet flows that do not exist in the Rule-Action table, the open flow switch generates a plurality of Packet-In messages and transmits them to the open flow controller.
  • Frequent packet-in message transmissions increase the load on the interface between the open flow switch and the open flow controller, resulting in a delay in the transmission of Packet-Out messages from the open flow controller to the open flow switch.
  • the delay in transmitting the Packet-Out message leads to a delay in updating the Rule-Action table of the open flow switch, thereby increasing the packet forwarding time.
  • IP is a 40-year-old protocol whose purpose is survival. Therefore, the current Internet, which is centered on media and interactive communication services, does not properly support performance / function. This is because it is difficult to introduce a new networking protocol besides IP.
  • the network operator (network operator) supports the flow level programmability for determining the path through which the packet is delivered, but the user / internet service provider does not support the service. It does not support the flow-level programmability for determining the path of a packet to which it belongs.
  • the network operator and the user / Internet service provider implements the desired function in the network and still does not support the technology to use it in the service.
  • the present invention solves the problems of the above-described router and SDN / open flow.
  • the present invention proposes a function-based network that allows network operators / internet service providers / users to easily and quickly introduce new network functions directly into network devices.
  • the present invention can execute a function of a network device using a smart packet capable of calling a function for a network function, thereby providing a new network function and protocol as well as a new network service as well as an IP protocol.
  • the present invention allows the network operator / internet service provider / user to acquire static / dynamic information of the network by using a smart packet including function execution information, thereby facilitating network management.
  • FIG. 11 is a structural diagram of a mobile communication system for packet generation according to an embodiment of the present invention.
  • a mobile communication system includes a FON device (Function-Oriented-Network Device, FON Device) 1100, a FON node (Function-Oriented-Network Node, FON Node) 1130, and a FON Manager (Function-). Oriented-Network Manager, FON Manager) (1120).
  • the FON device 1100 generates a DB 1104 storing a function table having a function name and a function code, and generates and transmits a smart packet 1110 to the FON node. And a function processor 1102 capable of receiving smart packets from the FON node.
  • the smart packet 1110 means a function based packet and does not include an IP address.
  • the function processor 1102 may execute a function specified in the function call field of the smart packet 1110 received from the FON node 1130.
  • the function processor 1102 receives a function distribution message from the FON manager 1120, and stores and updates function table information of the FON manager 1120 included in the function distribution message in the function table of the FON device 1100.
  • Perform The function processor 1102 may verify the smart packet 1110 using the function table stored in the DB 1104 when the smart packet 1110 is generated.
  • the FON node 1130 receives a function table containing an executable function name, a function code, a function usage count, or statistical information, and receives a smart packet and extracts information of a function call field. It consists of a function processor 1132 that calls and executes a function corresponding to the function name. The function processor 1132 extracts the function code to be executed from the DB 1134 to perform dynamic binding, and performs a function of executing the dynamically bound function. The function processor 1132 may also specify the result of the function execution in the payload of the smart packet and send the smart packet to another FON device or FON node.
  • the function processor 1132 receives the function distribution message from the FON manager 1120 and stores and updates the function table information of the FON manager 1120 included in the function distribution message in the function table of the FON node 1130. Perform.
  • the function processor 1132 also forwards the function distribution message received from the FON manager to the FON device, thereby enabling the FON manager to send the function distribution message to the FON device.
  • the function processor 1132 When the function processor 1132 is requested to execute a function that does not exist in the function table from the FON device 1100, the function processor 1132 requests a function code that does not exist in the function table from the FON manager 1120, and the FON manager 1120. Can perform the function of receiving a function code.
  • the function processor 1132 receives the function deletion message from the FON manager 1120, deletes the function name information and the function code information included in the function deletion message from the function table and performs dynamic unbinding for the corresponding function. Can be.
  • the function processor 1132 receives a function addition message from the FON manager 1120, and adds function name information and function code information included in the function addition message to the function table.
  • the function processor 1132 manages a function table stored in the DB 1134 and reports the function usage information for each user to the FON manager 1120.
  • the FON manager 1120 manages a function table 1124a having an executable function name and a function code, a subscriber information, and an accounting table that manages billing information according to user use of functions. DB 1124 of 1124b).
  • the FON manager 1120 also includes a management processor 1122 that extracts the function table 1124a from the DB 1124 and transmits the function table 1124a to the FON device 1100 or the FON node 1130.
  • the management processor 1122 adds a new function that can be executed in the FON node 1130 to the function table of the FON manager 1120, and sends a function addition message to the FON node 1130 to send the function table of the FON node 1130. You can add function name information and function code information to.
  • the management processor 1122 may delete the specific function name information and the function code information of the function table stored in the FON node 1130 by transmitting a function deletion message to the FON node 1130.
  • the management processor 1122 may receive a function code request from the FON node 1130, extract a function code from the function table 1124a of the DB 1124, and deliver the function code.
  • the management processor 1122 receives function usage information for each user from the FON node 1130, calculates billing information for function usage for each user, and stores / manages the information in the accounting table 1124b.
  • the management processor 1122 transmits a function distribution message to the FON node 1130, thereby distributing the function table of the FON manager 1120 to the FON device 1100 or the FON node 1130.
  • the FON device 1100 is a user equipment, a sensor, a desktop computer, a tablet using a wireless transmission technology such as LTE, WiMAX, Wi-Fi, Bluetooth, ZigBee, and wired transmission technology such as Ethernet. Applicable to computers, laptops, etc.
  • the FON node 1130 may be a router, a switch, a Wi-Fi access point (Wi-Fi access point), an evolved NodeB (eNB), a Packet Data Network Gateway (PGW), a Serving Gateway (SGW), a Home evolved NodeB (HeNB) FGW ( It can be applied to Femtocell Gateway) and can exist as an independent device.
  • Wi-Fi access point Wi-Fi access point
  • eNB evolved NodeB
  • PGW Packet Data Network Gateway
  • SGW Serving Gateway
  • HeNB Home evolved NodeB FGW
  • the FON manager 1120 may be applied to a mobility manager entity (MME), an open flow controller, a simple network management protocol manager (SNMP manager), or the like and may exist as an independent device.
  • MME mobility manager entity
  • SNMP manager simple network management protocol manager
  • FIG. 12 is a diagram illustrating a smart packet structure according to an embodiment of the present invention.
  • the smart packet 1200 of FIG. 12 includes a trailer 1205, a payload 1207, a function call field 1210, a source MAC header 1230, and a destination MAC header 1240.
  • the function invocation field 1210 may include an IPv4 / IPv6 address (hereinafter referred to as an “IP address”) 1250, a TCP / UDP port number 1260, and the like. That is, in order to provide compatibility with the IP network in consideration of the IP protocol and the stack structure, the IPv4 / IPv6 address may be selectively included in the function call field. If it is not an IP network, do not include an IPv4 / IPv6 address.
  • the function call field 1210 includes function name information to be called and may include a plurality of function name information.
  • the input and output parameters of the function to be called can be inserted into the payload.
  • 13 and 14 are exemplary diagrams of a network configuration to which the present invention is applicable.
  • FIG. 13 is a mobile communication network structure utilizing the present invention
  • Figure 14 shows a wired and wireless network structure using the present invention.
  • the FON device is applied to the sensors 1312 and 1314 and the user terminal 1310.
  • the sensors 1312 and 1314 communicate with the femtocell base station 1316 using transmission technologies such as Bluetooth and ZigBee, and the user terminal 1310 uses the transmission technology such as LTE for the femtocell base station 1316 or eNB 1322.
  • Communicate with The femtocell base station 1316 in FIG. 13 has a FON node applied thereto, and supports, for example, all Bluetooth / ZigBee / LTE / LTE-A transmission technologies.
  • the eNB 1322 has a FON node applied thereto, and supports, for example, LTE or LTE-A transmission technology.
  • the FGW 318, the eNB 1322, the Serving Gateway (SGW) 1324, and the Packet Data Network Gateway (PGW) 1326 are applied with a FON node, and the Mobile Mobility Entity (MME) 1320 is a FON Manager. It has an applied structure.
  • MME Mobile Mobility Entity
  • a FON device is applied to Host 1 1410 and communicates with a Wi-Fi AP 1412 using a wireless transmission technology such as Wi-Fi.
  • Host 2 1424 is applied to a FON device in the same manner as Host 1 1410, and communicates with Router 5 1422 using a wired transmission technology such as Ethernet.
  • the FON nodes are applied to the Wi-Fi APs 1412 and routers 1 to 5 (1414, 1416, 1418, 1420, and 1422), and the FON manager 1426 may exist as an independent device as described above.
  • FIG. 15 is a detailed structural diagram of a FON device according to an embodiment of the present invention.
  • 15 is a detailed structural diagram in the case of an FON dedicated device.
  • a function-oriented-network layer (FON Layer) 1510 including a function processor (FON processor) and a DB 1514 is located on the MAC / PHY layer 1520.
  • a Function-Oriented-Network Application 1500 is located above the 1510.
  • the FON application 1500 may transmit data of the FON application 1500 to the FON layer 1510 using a socket interface.
  • FIG. 16 is another detailed structural diagram of a FON device according to an embodiment of the present invention.
  • FIG. 16 shows a structure of a FON / IP combined device which simultaneously supports a FON application and an IP application.
  • the IP Layer 1612 and the TCP / UDP Layer 1610 for the IP-based application are located on the MAC / PHY Layer 1640.
  • the FON Layer 1630 including the FON Processor 1632 and the DB 1634 is positioned at the same position as the IP Layer 1612 and the TCP / UDP Layer 1610.
  • the IP-based application 1600 transmits data using the IP-based Socket interface.
  • the FON-based application 1620 transmits data using the FON-based Socket interface.
  • FON-based Socket interface can be implemented by modifying IP-based Socket interface for compatibility with existing applications based on IP and ease of development.
  • the IP packet generation / transmission and reception process in the FON device is the same as the conventional end-to-end application data communication method, and is illustrated in FIGS. 5, 6, 7, 8, 9, and 10. This is the same for existing services in terms of compatibility.
  • 17 is a flowchart illustrating a smart packet generation / transmission and reception process in a FON application.
  • the FON / IP-compatible device or the FON-only device calls the socket () function in step 1701 and creates a socket for FON communication.
  • the FON / IP-compatible device or the FON-only device attempts to connect to the FON node by calling the connection () function in step 1703.
  • the FON / IP-compatible device or the FON-only device determines whether to transmit data to or receive data from the FON node.
  • the FON / IP-compatible device or the FON-only device When transmitting data to the FON node, the FON / IP-compatible device or the FON-only device creates a smart packet by calling the spCreate () function in step 1707.
  • the FON / IP-compatible device or the FON-only device adds a function to be executed in the FON node to the function call field of the smart packet by calling spAdd () in step 1709.
  • call spAdd () repeatedly to add the function to be executed in the FON node to the function call field.
  • an example of various functions will be described with reference to FIG. 25 to be described later.
  • the FON / IP-compatible device or the FON-only device calls the spTerminate () function to complete the smart packet generation.
  • the write () function is called to request the smart packet transmission to the FON layer. If there is data to be transmitted continuously, the FON / IP-compatible device or the FON-only device repeatedly calls spCreate (), spAdd (), spTerminate (), and write () to request data transmission to the FON Layer. If there is no more data to transmit in step 1719, the FON / IP-compatible device or FON-only device terminates the established connection with the FON node by calling the close () function in step 1721.
  • the FON / IP-compatible device or the FON-only device checks the payload of the smart packet received in step 1717 and calls the read () function to call the FON node in the FON Layer. It requests data extraction and reception of FON application from smart packet received from. When you no longer want to receive data or there is no more data to receive, the FON / IP device or the FON-only device terminates the established connection with the FON node by calling the close () function.
  • FIG. 18 illustrates an example of socket control related program code of a FON-based application in a FON device.
  • Reference numeral 1800 denotes an example of the socket () function in step 1701 of FIG.
  • Reference numeral 1810 represents an example of a connection function in step 1703 of FIG. 17.
  • FIG. 18 is a function-based (FON) socket as compared to FIG. 6, and it can be seen that the IP address (for example, 0.102.111.110) is described in the connection function as compared to FIG. 6.
  • IP address for example, 0.102.111.110
  • 19 is a flowchart illustrating a smart packet transmission process in a FON layer.
  • the FON layer receives a smart packet from the FON application in step 1901.
  • the FON layer When the smart packet is received from the FON application, the FON layer additionally checks in step 1903 whether the function processor of the FON layer activates the function-oriented-network message validation.
  • FON message verification means checking whether a smart packet generated by a FON device can execute a network function without error on the FON node. If the FON verification message function is not activated, the function processor of the FON layer constructs a smart packet in step 1911 and forwards the smart packet configured in step 1913 to Layer 2.
  • the function processor of the FON layer checks whether the smart packet can execute the network function without error in the FON node by using the function table in the DB of the FON layer in step 1905.
  • the structure 2000 of the function table consists of a function name field and a function code field, for example.
  • the function name field contains the name of the function executable in the FON node
  • the function code field contains the function source code for the function name.
  • the source code exists for the function that the FON device should perform at the request of a FON node or another FON device, but if the FON device calls a function of the FON node or another FON device, only the function name exists, so the FON message It is used to verify that it is a valid function call when it is created.
  • the function processor of the FON layer checks whether a function written in the function call field of the smart packet generated by the FON application exists in the function table.
  • the function processor of the FON layer discards the smart packet in step 1915 and returns an error code to the FON application in step 1917.
  • the function processor of the FON layer can determine that the function can be executed in the FON node in step 1909, and the next function name written in the smart packet is the function table. Repeatedly checks for the existence of the. If the function processor of the FON Layer exists in the function table until the last function written in the smart packet, the smart processor generates a smart packet including the last function in step 11911 and delivers the smart packet generated in step 1913 to Layer 2.
  • 21 is a flowchart illustrating a smart packet reception process in the FON layer.
  • the FON Layer receives the smart packet from Layer 2 in step 2101.
  • the function processor of the FON Layer extracts the function call field of the smart packet in step 2103 to search for the function name.
  • the function processor of the FON layer determines whether the function name found in step 2105 is PacketSend (). If the searched function name is not PacketSend (), the function processor of the FON layer executes the function.
  • the function processor of the FON layer searches for the payload of the smart packet in step 2107.
  • the function processor of the FON layer extracts FON application data from the payload found in step 2111 and delivers the FON application data to the FON application.
  • the function processor of the FON layer repeats the above process for all functions written in the function call field of the smart packet, and when the final function is reached, the smart packet reception process is completed.
  • 22 is a flowchart illustrating a smart packet reception process in a FON node.
  • the function processor of the FON node receives the smart packet from the FON device or the FON node in step 2201.
  • the function processor of the FON node Upon receiving the smart packet from the FON device or FON node, the function processor of the FON node extracts the function call field of the smart packet from the received smart packet in step 2203.
  • the function processor of the FON node searches for the name of the function to execute in step 2205. In this case, the function processor of the FON node searches for a function table stored in the DB in step 2207.
  • the function processor of the FON node finds and executes the function code from the function table in step 2209.
  • Function execution methods can exist in various ways, and the function processor of the FON node is based on function execution using dynamic binding.
  • the function processor of the FON node compiles the function codes existing in the function table stored in the DB to create an executable file, and stores the generated executable files in the DB.
  • the function processor of the FON node loads the executable file for the function specified in the function call field of the smart packet from the DB and executes it.
  • the FON node's function processor can release dynamic bindings for functions that do not execute.
  • the function processor of the FON node updates the statistics on the function whose execution is completed in step 2211, and determines whether all functions have been executed in step 2213. When all functions have finished executing, the function processor of the FON node terminates the operation. However, if all functions have not been executed, the function processor of the FON node returns to step 2205.
  • FIG. 23 is a structure and an exemplary view of a function table stored in a DB of a FON node.
  • the function table 2300 includes a function name field, a function code field, and a statistics field.
  • the function name field contains the name of the function executable in the FON node.
  • the function code field contains the function source code for the function name.
  • the statistics field contains the number of times the function is called.
  • the function processor of the FON node updates the statistics field in the function table for the function that has completed execution. After completing this process for all functions specified in the smart packet, the process of receiving the smart packet of the FON node is completed.
  • the function processor of the FON node identifies the FON device that sent the smart packet and sends the function usage information to the FON manager.
  • a FON device There are a variety of ways to identify a FON device, and can be identified using a unique user ID such as a 4G / 5G MAC address, a Wi-Fi address, a Bluetooth MAC address, and an International Mobile Subscriber Identity (ISMI). It also calculates the function name and the number of function calls called by the FON device.
  • a unique user ID such as a 4G / 5G MAC address, a Wi-Fi address, a Bluetooth MAC address, and an International Mobile Subscriber Identity (ISMI). It also calculates the function name and the number of function calls called by the FON device.
  • ISMI International Mobile Subscriber Identity
  • the user identification information and the function usage information are transmitted to the FON manager using the function usage information report message shown in FIG. 24.
  • 24 is a format illustrating an example of a function usage information report message.
  • the function usage information report message is a message sent from the FON device to the FON manager. It can be seen from FIG. 24 that the FON device is identified using, for example, ISMI.
  • the function usage information report message includes function call information. The cost of charging according to the number of function calls can be calculated by extracting the function call information.
  • 25 is a diagram illustrating an example of a list of basic functions supported by a FON node.
  • FIG. 25 illustrates an example of a function used in operation 1709 of FIG. 17.
  • FON Manager can distribute the function table stored in the FON Manager's DB to FON device and FON node.
  • the FON Manager's management processor extracts the function table stored in the DB, generates a function distribution message, and sends the generated function distribution message to the FON node.
  • the function table information of the FON manager is distributed to the FON node.
  • PacketSend For packet delivery, the functions used include PacketSend (), PacketInsertField (), PacketRemoveField (), PacketAddField (), and PacketPort ().
  • PacketSend is a function necessary to send a packet to a request point
  • PacketInsertField is a function required to insert a requested value at a specific position (field) of a packet
  • PacketRemoveField is a value of a specific position (field) of a packet.
  • PacketAddField is a function required to insert a requested value at the end of a packet
  • PacketPort is a function required to read a port number (s) to which a packet is transmitted.
  • SystemRead () function is used to retrieve system information
  • SystemRead () function is necessary to read system information of FON node.
  • SubscriberRRead () function When searching user information, SubscriberRRead () function is used, and SubscriberRRead () function is necessary to read user / terminal information connected to FON node.
  • StorageAvailability Functions required when using user storage space include StorageAvailability (), StorageCreate (), StorageRead (), StorageWrite (), and StorageRemove ().
  • the StorageAvailability () function is used to check whether a FON node has a user requested variable.
  • StorageCreate is a function required to create a variable requested by a user in a FON node.
  • the StorageRead () function is used to read a value into a variable created by a user in a FON node.
  • the StorageWrite () function is a function for storing a value in a variable created by a user in a FON node.
  • the StorageRemove () function is used to remove a variable requested by a user from a FON node.
  • MathRandom ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • MathRandom () is a function that is used to calculate the result of the Random function within the input range.
  • MathGetMax () is a function that is required to compare input values and return the maximum value.
  • 26 is a diagram illustrating a function distribution message according to an embodiment of the present invention.
  • the Command property which indicates the purpose of the message, has a value of "Publication", and contains the function name, function code, input parameter, output parameter information, and Contains target information.
  • Target information in FIG. 26 becomes a FON device and a FON node.
  • the FON node receiving the created function distribution message further includes the attribute value "FON Device" in the Target attribute
  • the FON node transmits the function distribution message to all FON devices communicating with the FON node.
  • the FON Manager will distribute the function table information to the FON device.
  • the FON Manager can issue a command to delete a specific function among the functions deployed in the FON node.
  • the function deletion process is as follows.
  • the management processor of the FON manager When the network operator wants to delete a specific function among the functions in the function table of the FON node, the management processor of the FON manager generates a function deletion message and sends it to the FON node, thereby deleting the specific function in the FON node. do.
  • FIG. 27 shows a structure diagram and an exemplary view of a function deletion message according to an embodiment of the present invention.
  • the command attribute indicating the purpose of the message has a "Delete" attribute value, and includes a function name, a function code, input parameters, output parameter information to be deleted, and target information of a device to perform function deletion.
  • Target information includes, for example, a FON device and a FON node.
  • the FON Manager sends the function delete message to the FON node, and the FON manager deletes the specific function in the function table of the FON node by deleting the function information specified in the function delete message from the function table. Done.
  • the FON Manager can add new functions created by the network operator or the 3rd-Party operator to the FON node and add them.
  • the new function transfer and addition process is as follows.
  • the FON Manager's management processor can add a new function to the FON node's function table by generating a function add message and sending it to the FON node. .
  • FIG. 28 is a diagram illustrating a function addition message structure and an exemplary view according to an embodiment of the present invention.
  • the command attribute indicating the purpose of the message has a "Add" attribute value and includes function name, function code, input parameter, output parameter information to be deleted and target information of a device to perform function addition.
  • Target information includes, for example, a FON device and a FON node.
  • the FON Manager sends a function add message to the FON node, which receives the function information specified in the function add message into the function table of the FON node, so that the FON manager adds a new function to the function table of the FON node. Will be added.
  • the FON manager When the FON manager receives the function usage information message from the FON node, the FON manager manages billing information according to the use of the function.
  • the billing information management process is as follows.
  • the management processor of the FON manager manages the accounting table stored in the DB.
  • 29 shows an accounting table structure diagram according to an embodiment of the present invention.
  • the management processor of the FON manager extracts FON node information from the received function usage information report message to identify a user, and stores the identified user information in the subscriber attribute of the accounting table 2900.
  • the management processor of the FON manager extracts the function call information from the function usage information report message to calculate the charging cost according to the number of function calls.
  • the calculated charging cost is stored in the charging information attribute of the accounting table. This process is performed by the FON manager's management processor each time a function usage information report message is received from the FON node, thereby managing the charging information according to the user's network function usage.
  • 26, 27, and 28 are examples for exemplifying the present invention, and may be implemented in other languages and displays.
  • FIG. 30 is a scenario illustrating an example of data communication between a sensor and a user terminal in a general 4G / 5G mobile communication network.
  • the femtocell base station 3006 supports Bluetooth transmission technology and LTE or 5G wireless transmission technology
  • the sensor 3002 and the user terminal 3004 belonging to the same femtocell base station 3006 do not communicate directly with each other, and do not directly communicate with each other.
  • Internet of Things (IoT) communication is performed between the sensor 3002 and the user terminal 3004 via the anchor 3008 and the DNS server 3010.
  • the user terminal 3004 transmits a DNS request message to the DNS server 3010 via the femtocell base station 3006 and the IP anchor device 3008.
  • the DNS server 3010 transmits a DNS response message to the user terminal 3004 via the IP anchor 3008 and the femtocell base station 3006.
  • the user terminal 3004 obtains the IP address information of the sensor.
  • the user terminal attempts to establish a TCP connection to a sensor in the same base station using the obtained IP address.
  • the TCP SYNC message is transmitted to the femtocell base station 3006 and the IP Anchor 3008, and the IP Anchor 3008 sends the TCP SYNC message to the femtocell base station 3006 to which the sensor 3002 belongs.
  • the femtocell base station 3006 identifies the sensor to send the TCP SYNC message and transmits the TCP SYNC message to the sensor 3002 using a Bluetooth transmission technology.
  • the sensor 3002 Upon receiving the TCP SYNC message, the sensor 3002 generates a TCP ACK message for the TCP SYNC message and transmits it to the femtocell base station 3006.
  • Receiving TCP ACK Message The femtocell base station 3006 receives the TCP ACK message to the IP Anchor 3008, and the IP Anchor 3008 transmits the TCP ACK message to the femtocell base station 3006 to which the user terminal 3004 belongs.
  • the femtocell base station 3006 identifies the user terminal 3004 to send the TCP ACK message and transmits the TCP ACK message to the corresponding user terminal 3004 using LTE or 5G wireless transmission technology.
  • the transmission process of the application data of the user terminal 3004 and the sensor and the TCP connection establishment termination message is also performed in the same manner as the TCP SYNC and TCP ACK transmission processes.
  • This conventional transmission technique increases signaling in the mobile communication network, increases the load of the IP anchor 3008 and the DNS server 3010 and the traffic of the core network.
  • FIG. 31 is a scenario illustrating a data communication process between a user terminal and a sensor when the transmission scenario of FIG. 30 is applied to the present invention.
  • the user terminal specifies the PacketSend () function in the function call field of the smart packet, and transmits the data to be sent to the sensor and the Bluetooth MAC address of the sensor in the payload to the femtocell base station.
  • the femtocell base station includes a FON node and can process smart packets.
  • the femtocell base station including the FON node extracts the data to be sent to the sensor used as the input parameter of the PacketSend () function from the payload and the Bluetooth MAC address of the sensor and uses it as the input parameter of the PacketSend () function. Execute the PacketSend () function specified in the smart packet function call field.
  • the femtocell base station transmits the smart packet of the user terminal received using the LTE or 5G transmission technology to the sensor using the Bluetooth transmission technology in step 3103.
  • the femtocell base station may inform the user terminal that the smart packet has been processed normally.
  • Such an embodiment of the present invention can reduce signaling in a mobile communication network, distribute the load of devices such as an IP anchor and a DNS server, and reduce traffic generated in a core network, compared to the related art.
  • the embodiment of the present invention can increase the use efficiency of radio resources by reducing the load on the radio link.
  • Network devices consist of equipment such as switches or routers.
  • FIG 33 illustrates an end-to-end packet transmission path information collection scenario according to an embodiment of the present invention.
  • the network device consists of a FON node. Host 1 and Host 2 consist of FON devices. Network devices including the FON node download the network monitoring function from the FON manager and perform dynamic binding. The user or the network manager includes execution information on the network monitoring function in the smart packet and transmits it to the FON node. The FON node receiving the smart packet executes the network monitoring function specified in the smart packet, stores the measured network monitoring information in the DB, and transmits the measured network monitoring information to the user or the network manager.
  • Such operation characteristics of the present invention make it possible to accurately grasp the situation and problems of the network from the viewpoint of users and management.
  • 34 illustrates an example of packet transmission optimization using a biomimetic ant population algorithm according to an embodiment of the present invention.
  • Host 1 and Host 2 act as FON devices, and network devices act as FON nodes.
  • the network devices download the biomimetic ant population algorithm related functions from the FON manager and perform dynamic binding.
  • Host 1 uses the biomimetic ant population algorithm to write function execution information that determines the optimized transmission path among the data transmission paths from Host 1 to Host 2 in the function call field of the smart packet to operate the FON node.
  • the network node receiving the smart packet executes the biomimetic ant population algorithm functions specified in the function call field of the smart packet. Once the function execution is completed, the smart packet is sent to any neighboring network device and the network device will also execute the biomimetic ant population algorithm functions specified in the smart packet.
  • the smart packet transmission and biomimetic ant population algorithm function execution process is repeatedly performed, and the smart packet arrives at Host 2.
  • the network device on which the FON node operates can determine an optimized transmission path based on the biomimetic ant algorithm.
  • 35 shows an example of conventional 3rd-Party web service or media service acceleration.
  • the user terminal requests three objects constituting the web page to different HTTP servers.
  • the user terminal generates an HTTP request message for the three objects constituting the web page and transmits it to the base station (BS).
  • the base station receiving the HTTP request message of the user terminal transmits the HTTP request message to different HTTP servers.
  • the HTTP request message reaches the third server's HTTP server 1, HTTP server 2, and HTTP server 3 via the mobile communication network.
  • 3rd-Party's HTTP server 1, HTTP server 2, and HTTP server 3 After receiving the HTTP request message, 3rd-Party's HTTP server 1, HTTP server 2, and HTTP server 3 generate an HTTP response message for the object constituting the web page and transmit it to the user terminal.
  • the HTTP response message transmitted from 3rd-Party's HTTP server 1, HTTP server 2, and HTTP server 3 is transmitted to the base station to which the user terminal belongs through the mobile communication network, and the base station transmits the HTTP response message to the user terminal.
  • the conventional web service acceleration method is a method of providing an accelerated web service to a user terminal in mobile communication by disposing a web server in a mobile communication network rather than placing a 3rd-Party web server on the Internet. It physically reduces the distance between the user terminal and the 3rd-Party web server, which accelerates the web service but does not accelerate the web service itself.
  • FIG 36 illustrates an example of 3rd-Party web service or media service acceleration according to an embodiment of the present invention.
  • the user terminal operates as a FON device and the base station operates as a FON node.
  • the base station downloads a function that implements the web service and transmission optimization technology provided by 3rd-Party from the FON manager, stores it in a DB, and dynamically binds it so that the function can be executed.
  • the user terminal (FON device) generates a smart packet for requesting a 3rd-Party web page and transmits it to the base station.
  • a function call field is created to request three objects in one smart packet and transmitted to the base station.
  • the base station executes a function specified in the smart packet to generate an HTTP request message for three objects constituting a web page and transmits the HTTP request message to 3rd-Party's HTTP server 1, HTTP server 2 and HTTP server 3. send.
  • the HTTP request message can be transmitted to the third-party HTTP server.
  • the 3rd-Party's HTTP server Upon receiving the HTTP request message, the 3rd-Party's HTTP server generates an HTTP response message for the object constituting the web page and transmits it to the base station.
  • the base station Upon receiving the HTTP response message from the 3rd-Party's HTTP server, the base station performs content optimization such as compressing or reducing the content according to the hardware characteristics of the user terminal if the object included in the HTTP response message is multimedia content. Send to the user terminal.
  • the embodiment of the present invention reduces the number of messages transmitted in the wireless section, minimizes the delay in the wireless section, optimizes the content of the 3rd-Party, and optimizes the transmission in the wired section such as the core network. It is possible to accelerate 3rd-Party web services or media services.
  • a new protocol can be introduced in addition to the IP network protocol.
  • the functions of the new network protocol as a function in the network and distributing it to the FON nodes and calling the function through smart packets, it is necessary for the network operator / user / Internet service provider to create their own new network protocol and introduce it into the network. It is possible.
  • network operators and user / Internet service providers can define their own routing policies. It supports sending traffic along the packet path determined by the function that you implement yourself.
  • the FON node may support additional functions required by the packet in addition to the packet transmission.
  • a network operator network operator
  • a user / internet service provider support flow-level programmability for determining a path through which a packet is delivered.
  • the network operator / user / Internet service provider is the only person by implementing the function of the new network protocol in the network as a function to distribute to the FON nodes, and call the function through the smart packet It is possible to create new network protocols and introduce them into the network. In addition, it supports the transmission of traffic through the packet path determined by the function directly implemented by the user.
  • the FON node can support the additional functions required by the packet in addition to the packet transmission.
  • DPI deep packet inspection
  • any such software may be, for example, volatile or nonvolatile storage, such as a storage device such as a ROM, whether or not removable or rewritable, or a memory such as, for example, a RAM, a memory chip, a device or an integrated circuit. Or, for example, CD or DVD, magnetic disk or magnetic tape and the like can be stored in a storage medium that is optically or magnetically recordable and simultaneously readable by a machine (eg computer).
  • a machine eg computer
  • the packet generation method may be implemented by a computer or a portable terminal including a controller and a memory, and the memory may include a program including instructions for implementing the embodiments of the present invention. It will be appreciated that this is an example of a machine-readable storage medium suitable for storing programs.
  • the present invention includes a program comprising code for implementing the apparatus or method described in any claim herein and a storage medium readable by a machine (such as a computer) storing such a program.
  • a program may be transferred electronically through any medium, such as a communication signal transmitted via a wired or wireless connection, and the present invention includes equivalents thereof as appropriate.
  • the packet generating apparatus may receive and store the program from a program providing apparatus connected by wire or wirelessly.
  • the program providing apparatus includes a program including instructions for causing the program processing apparatus to perform a packet generation method in a preset mobile communication system, a memory for storing information necessary for the packet generation method in a mobile communication system, and the graphic processing. It may include a communication unit for performing wired or wireless communication with the device, and a control unit for transmitting the program or the program automatically to the request or the graphics processing device.

Abstract

본 개시는 LTE와 같은 4G 통신 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 또는 pre-5G 통신 시스템에 관련된 것이다. 본 발명은 이동 통신 시스템에서 패킷 생성 방법 및 장치에 관한 것이다. 본 발명의 실시 예에 따른 방법은, 이동 통신 시스템에서의 디바이스에서 패킷 생성 방법에 있어서, 함수 기반의 패킷을 생성하는 과정; 및 상기 패킷을 타켓 노드로 전송하는 과정을 포함하고, 상기 패킷은 IP(internet protocol) 주소를 포함하지 않음을 특징으로 하는 한다.

Description

이동 통신 시스템에서 패킷 생성 방법 및 장치
본 발명은 이동 통신 시스템에서 패킷 생성 방법 및 장치에 관한 것이다.
4G(4th-Generation) 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G(5th-Generation) 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후(beyond 4G network) 통신 시스템 또는 LTE 시스템 이후(post LTE)의 시스템이라 불리고 있다.
높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역(예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서 전파의 경로 손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(full dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나(large scale antenna) 기술들이 논의되고 있다.
또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀(advanced small cell), 클라우드 무선 액세스 네트워크(cloud radio access network: cloud RAN), 초고밀도 네트워크(ultra-dense network), 기기 간 통신(device to device communication: D2D), 무선 백홀(wireless backhaul), 이동 네트워크(moving network), 협력 통신(cooperative communication), CoMP(coordinated multi-points), 및 수신 간섭제거(interference cancellation) 등의 기술 개발이 이루어지고 있다.
이 밖에도, 5G 시스템에서는 진보된 코딩 변조(advanced coding modulation: ACM) 방식인 FQAM(hybrid FSK and QAM modulation) 및 SWSC(sliding window superposition coding)과, 진보된 접속 기술인 FBMC(filter bank multi carrier), NOMA(non-orthogonal multiple access), 및 SCMA(sparse code multiple access) 등이 개발되고 있다.
한편, 아이피(IP : Internet Protocol) 네트워킹은 인터넷 기술의 비약적인 발전에 힘입어 급속한 발전을 이루고 있는 기술이다. 이러한 아이피 네트워킹에서는 각각 고정된 주소 즉, 아이피 주소(IP Address)를 가지고 각 사용자들 및 특정 서버가 동작하게 되며, 상기 주소를 근간으로 하여 라우팅(routing)이 이루어진다.
한편, 이동통신 시스템에서도 단말에게 보다 많은 데이터를 제공하기 위해 여러 가지 방식들이 제안되고 있으며, 이러한 방식 중 하나로 이동 단말에 IP 주소를 할당하는 즉, 모바일 아이피(Mobile IP)라는 개념이 도입되기에 이르렀다.
라우터는 IP 네트워킹을 지원함으로써, 글로벌 네트워크에서 종단의 단말 간 통신을 가능하게 한다. 하지만 IP 네트워킹에서의 IP 주소는 글로벌 네트워크에서 단말의 고유한 식별자로만 사용하기 때문에 단순 패킷 전송만을 지원할 뿐, 멀티미디어 및 상호교환적인 통신 서비스를 지원하기에 어려움이 있다. 더 나아가 다양한 응용서비스들이 만들어지는 환경에서 IP 주소만으로는 서비스를 인식할 수 없기 때문에 네트워크 안에서 부가 서비스를 제공하는 것이 불가능하다. 또 라우터는 제어 평면과 데이터 평면을 하나의 장치로 통합하고, 라우터 마다 서로 다른 제어 평면 정보를 가지면서 각자 독립적으로 동작하기 때문에, 새로운 네트워킹 프로토콜을 도입하기에 어려운 구조를 가지고 있다. 또한 라우터는 완전 분산 방식의 라우팅 알고리즘과 프로토콜을 사용하기 때문에, 망운영자(Network Operator)가 라우팅 정책을 직접 정의하지 못하는 문제를 가지고 있다. 사용자(User)와 인터넷서비스제공자(Internet Service Provider)도 라우팅 정책에 관여하지 못하며, 네트워크의 정적/동적 정보를 확인할 수도 없는 문제점이 있다.
본 발명은 이동 통신 시스템에서 패킷 생성 방법 및 장치를 제공한다.
본 발명은 사용자/인터넷 서비스 제공자가 원하는 기능을 직접 망에 적용하는 방법 및 장치를 제공한다.
본 발명의 실시 예에 따른 방법은, 이동 통신 시스템에서의 디바이스에서 패킷 생성 방법에 있어서, 함수 기반의 패킷을 생성하는 과정; 및 상기 패킷을 타켓 노드로 전송하는 과정을 포함하고, 상기 패킷은 IP(internet protocol) 주소를 포함하지 않음을 특징으로 한다.
본 발명은 사용자/인터넷 서비스 제공자가 원하는 기능을 직접 망에 적용할 수 있다.
도 1은 라우터(Router)의 패킷 전송 방식을 지원하는 라우터 구조도;
도 2는 라우터(Router)의 패킷 전송 방식을 지원하는 IP 패킷 구조도;
도 3은 오픈 플로우의 패킷 전송 방식을 지원하는 라우터 구조도;
도 4는 오픈 플로우의 패킷 전송 방식을 지원하는 라우터에서의 IP 패킷 처리 과정을 도시한 흐름도;
도 5는 IP 어플리케이션(IP Application)의 IP 패킷 생성/전송 및 수신 과정을 나타낸 흐름도;
도 6은 도 5에서 설명한 IP 기반 어플리케이션의 소켓 제어 관련 프로그램 코드의 예시도;
도 7은 TCP/UDP Layer에서의 TCP/UDP 세그먼트 전송 과정을 나타낸 흐름도;
도 8은 IP Layer에서의 IP 패킷 전송 과정을 나타낸 흐름도;
도 9는 IP Layer에서의 IP 패킷 수신 과정을 나타낸 흐름도;
도 10은 TCP/UDP Layer에서의 TCP/UDP 세그먼트 수신 과정을 나타낸 흐름도;
도 11은 본 발명의 실시 예에 따른 패킷 생성을 위한 이동 통신 시스템 구조도;
도 12는 본 발명의 실시 예에 따른 스마트 패킷 구조도;
도 13 및 도 14는 본 발명이 적용 가능한 네트워크 구성의 예시도;
도 15는 본 발명의 실시 예에 따른 FON 디바이스의 세부 구조도;
도 16은 본 발명의 실시 예에 따른 FON 디바이스의 다른 세부 구조도;
도 17은 FON 어플리케이션에서의 스마트 패킷 생성/전송 및 수신 과정을 나타낸 흐름도;
도 18은 FON 디바이스에서 FON 기반 어플리케이션의 소켓 제어 관련 프로그램 코드의 예시도;
도 19는 FON Layer에서의 스마트 패킷 전송 과정을 흐름도;
도 20은 FON 디바이스의 DB에 저장되어 있는 함수 테이블의 구조도;
도 21은 FON Layer 에서의 스마트 패킷 수신 과정을 나타낸 흐름도;
도 22는 FON 노드에서의 스마트 패킷 수신 처리 과정을 나타낸 흐름도;
도 23은 FON 노드의 DB에 저장되어 있는 함수 테이블의 구조 및 예시도;
도 24는 함수 이용 정보 보고 메시지의 일 예를 도시한 포맷;
도 25는 FON 노드가 지원하는 기본 함수에 대한 리스트의 예시도;
도 26은 본 발명의 실시 예에 따른 함수 배포 메시지 구조도 및 예시도;
도 27은 본 발명의 실시 예에 따른 함수 삭제 메시지 구조도 및 예시도;
도 28은 본 발명의 실시 예에 따른 함수 추가 메시지 구조도 및 예시도;
도 29는 본 발명의 실시 에에 따른 회계 테이블 구조도;
도 30은 일반적인 4G/5G 이동통신 네트워크에서의 센서와 사용자 단말 간의 데이터 통신의 예시를 나타낸 시나리오;
도 31은 도 30의 전송 시나리오를 본 발명을 적용했을 때의 사용자 단말과 센서 간의 데이터 통신 과정을 나타낸 시나리오;
도 32는 일반적인 종단 간 패킷 전송 경로 정보 수집 예시도;
도 33은 본 발명의 실시 예에 따른 종단 간 패킷 전송 경로 정보 수집 시나리오;
도34는 본 발명의 실시 예에 따른 생체모방 개미 집단 알고리즘을 활용한 패킷 전송 최적화 예시를 나타낸 도면;
도 35는 종래의 3rd-Party 웹 서비스 또는 미디어 서비스 가속화 예시도; 및
도 36은 본 발명의 실시 예에 따른 3rd-Party 웹 서비스 또는 미디어 서비스 가속화 예시도.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다. 이때 첨부된 도면에서 동일한 구성 요소는 가능한 동일한 부호로 나타내고 있음에 유의하여야 한다. 또한 본 발명의 요지를 흐리게 할 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략할 것이다.
또한 이하에서 설명되는 본 명세서 및 청구범위에 사용된 용어나 단어는 통상적이거나 사전적인 의미로 한정해서 해석되어서는 아니되며, 발명자는 그 자신의 발명을 가장 최선의 방법으로 설명하기 위해 용어의 개념으로 적절하게 정의할 수 있다는 원칙에 입각하여 본 발명의 기술적 사상에 부합하는 의미와 개념으로 해석되어야만 한다.
본 출원에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
본 발명의 실시 예는 롱 텀 에볼루션(LTE: Long-Term Evolution, 이하 'LTE'라 칭하기로 한다) 이동 통신 시스템과, 롱 텀 에볼루션-어드밴스드(LTE-A: Long-Term Evolution-Advanced, 이하 'LTE-A'라 칭하기로 한다) 이동 통신 시스템과, 고속 하향 링크 패킷 접속(high speed downlink packet access: HSDPA, 이하 'HSDPA'라 칭하기로 한다) 이동 통신 시스템과, 고속 상향 링크 패킷 접속(high speed uplink packet access: HSUPA, 이하 'HSUPA'라 칭하기로 한다) 이동 통신 시스템과, 3세대 프로젝트 파트너쉽 2(3rd generation project partnership 2: 3GPP2, 이하 '3GPP2'라 칭하기로 한다)의 고속 레이트 패킷 데이터(high rate packet data: HRPD, 이하 'HRPD'라 칭하기로 한다) 이동 통신 시스템과, 3GPP의 광대역 부호 분할 다중 접속(WCDMA: Wideband Code Division Multiple Access, 이하 'WCDMA'라 칭하기로 한다) 이동 통신 시스템과, 3GPP2의 부호 분할 다중 접속(CDMA: Code Division Multiple Access, 이하 'CDMA'라 칭하기로 한다) 이동 통신 시스템과, 국제 전기 전자 기술자 협회(IEEE: Institute of Electrical and Electronics Engineers, 이하 'IEEE'라 칭하기로 한다) 802.16m 통신 시스템과, 진화된 패킷 시스템(EPS: Evolved Packet System, 이하 'EPS'라 칭하기로 한다)과, 모바일 인터넷 프로토콜(Mobile Internet Protocol: Mobile IP, 이하 'Mobile IP '라 칭하기로 한다) 시스템 등과 같은 다양한 통신 시스템들에 적용 가능함은 물론이다.
패킷 라우팅 및 포워딩 기술로, 제어 평면(Control Plane)과 데이터 평면(Data Plane)이 통합되어 있는 라우터(Router)의 패킷 전송 방식과, 제어 평면과 데이터 평면이 분리된 형태를 가지는 오픈 플로우(openflow)의 패킷 전송 방식이 있다.
도 1은 라우터(Router)의 패킷 전송 방식을 지원하는 라우터 구조도이다.
라우터(100)는 IP 패킷에 대한 라우팅 및 포워딩을 제공하기 위해서 라우팅 프로세서(Routing Processor)(110), 포워딩 프로세서(120), DB(Database)(130)를 포함한다.
라우팅 프로세서(110)는 목적지 IP 주소에 따른 물리적 포트 정보(이하, "포트 정보"이라 칭함)를 포함하는 라우팅 테이블(140)을 생성한다.
DB(130)는 생성된 라우팅 테이블을 저장한다.
포워딩 프로세서(120)는 IP 패킷을 수신하면, 해당 IP 패킷의 목적지 IP 주소에 해당하는 물리 포트를 식별하기 위해서 DB(130)에 저장되어 있는 라우팅 테이블(140)을 참조한다. 포워딩 프로세서(120)는 수신한 패킷의 목적지 IP 주소가 라우팅 테이블에 존재하면, 목적지 IP 주소에 해당하는 물리 포트로 포워딩한다. 그러나, 수신한 패킷의 목적지 IP 주소에 대한 정보가 라우팅 테이블에 존재하지 않으면 포워딩 프로세서(120)는 디폴트 물리 포트로 포워딩한다.
도 2는 라우터(Router)의 패킷 전송 방식을 지원하는 IP 패킷 구조도이다.
도 2의 IP 패킷(200)은 트레일러(Trailer)(205), 페이로드(Payload)(207), 발신지 L3/L4 주소 필드(210), 목적지 L3/L4 주소 필드(220), 발신지 MAC 헤더(230), 목적지 MAC 헤더(240)를 포함한다. 발신지 L3/L4 주소 필드(210), 목적지 L3/L4 주소 필드(220)에는 IPv4/IPv6 주소(이하, "IP 주소"이라 칭함)(250), 및 TCP/UDP 포트 넘버(260) 등을 포함한다.
도 3은 오픈 플로우의 패킷 전송 방식을 지원하는 라우터 구조도이다.
도 3의 라우터는 도 1의 라우터와 달리, 라우팅 프로세서(310)와 포워딩 프로세서(330)가 분리된다.
오픈 플로우 제어부(300)는 라우팅 프로세서(310), DB(312)를 포함한다.
오픈 플로우 스위치(320)는 포워딩 프로세서(330)와 DB(332)를 포함한다.
라우팅 프로세서(310)는 라우팅 테이블을 생성한다. DB(312)는 생성된 라우팅 테이블을 저장한다. 오픈 플로우 제어부(300)는 오픈 플로우 프로토콜(315)을 이용하여 패킷을 제어하기 위한 패킷 제어 정보를 오픈 플로우 스위치(320)로 전달한다. 패킷 제어 정보를 수신한 오픈 플로우 스위치(320)는 패킷 제어 정보를 Rule-Action 테이블(334)에 저장한다.
도 4는 오픈 플로우의 패킷 전송 방식을 지원하는 라우터에서의 IP 패킷 처리 과정을 도시한 흐름도이다.
이하에서 기술되는 포워딩 프로세서(330)는 도 4의 동작을 수행하는 제어기 또는 프로세서로 이해될 수 있음은 물론이다.
포워딩 프로세서(330)는 401 단계에서 IP 패킷을 수신한다. 이후에 포워딩 프로세서(330)는 403 단계에서 수신한 IP 패킷의 IP 패킷 헤더 정보(이하, " IP 패킷 헤더"라 칭함)를 확인한다. 포워딩 프로세서(330)는 IP 패킷 헤더를 통해 목적지/발신지 MAC 주소, 목적지/발신지 IP 주소, 및 목적지/발신지 TCP 포트 번호 등의 헤더 정보를 추출한다.
포워딩 프로세서(330)는 405 단계에서 추출된 헤더정보가 룰 액션 테이블(Rule-Action table)(334)에 작성되어 있는 Rule 정보와 일치하는지를 확인한다. 만약, 추출된 헤더정보와 Rule-Action 테이블(334)이 일치하지 않으면, 오픈 플로우 제어부(300)는 수신한 패킷을 포워딩 프로세서(330)로 포워딩하고, 오픈 플로우 제어부(300)의 결정에 따라 수신한 패킷을 특정 물리 포트로 포워딩하거나 폐기할 수 있다.
추출된 헤더정보와 Rule-Action 테이블(334)이 일치하면, 포워딩 프로세서(330)는 407 단계에서 Rule-Action 테이블(334)의 Action 타입을 확인 및/또는 결정한다.
포워딩 프로세서(330)는 Action 정보(또는 타입)에 따라 플로우 제어 및 포워딩을 수행한다. Action 타입이 "드랍"인 경우, 포워딩 프로세서(330)는 409 단계에서 패킷을 드랍(drop)한다.
Action 타입이 "전달"인 경우, 포워딩 프로세서(330)는 411 단계에서 단일 또는 복수 개의 물리 포트로 수신된 패킷을 포워딩한다.
Action 타입이 "보고"인 경우, 포워딩 프로세서(330)는 413 단계에서 보고하기 위해 오픈 플로우 제어부(300)로 수신된 패킷을 포워딩한다.포워딩 프로세서(330)는 415 단계로 진행하여, 409 단계, 411 단계, 및 413 단계와 같이, 실행이 완료된 함수에 대한 통계치를 업데이트한다.
상기에 기술한 라우팅 및 포워딩을 지원하는 네트워크에서의 종단 간 어플리케이션 데이터 통신에 대한 기술로써, TCP/IP 기반의 소켓(Socket) 인터페이스를 이용한 어플리케이션 데이터 통신 기술이 있다. 이하에서는 TCP/IP 기반의 소켓(Socket) 인터페이스를 이용한 어플리케이션 데이터 통신 기술에 대해서 설명하기로 한다.
도 5는 IP 어플리케이션(IP Application)의 IP 패킷 생성/전송 및 수신 과정을 나타낸 흐름도이다.
도 5의 동작은 TCP/IP 프로토콜을 지원하는 단말에서 수행된다. IP 어플리케이션은 501 단계에서 socket() 함수를 호출하여 IP 통신을 위한 socket을 생성한다. IP 어플리케이션은 503 단계에서 단말 연결 함수(connection() 함수)를 호출하여 원격지 호스트로 연결을 시도한다.
IP 어플리케이션은 505 단계에서 원격지 호스트로의 데이터를 전송하는 것인지 수신하는 것인지를 판단한다.
만약, 원격지 호스트로의 데이터를 전송하는 경우, IP 어플리케이션은 507 단계에서 write() 함수를 호출하여 TCP/UDP Layer로 데이터 전송을 요청한다. 511 단계에서와 같이, 더 이상 전송할 데이터가 없을 경우, IP 어플리케이션은 513 단계에서 close() 함수를 호출함으로써 원격지 호스트와 설정되어 있던 연결을 종료한다.
만약, 원격지 호스트로부터 데이터를 수신할 경우, IP 어플리케이션은 509 단계에서 read() 함수를 호출하여 TCP/UDP Layer에 원격지 호스트로부터 수신한 IP 패킷에서 IP 어플리케이션의 데이터 추출 및 수신을 요청한다. 이후, 511 단계에서와 같이, 더 이상 데이터를 수신하기를 원하지 않거나 더 이상 수신할 데이터가 없을 경우, IP 어플리케이션은 513 단계에서 close() 함수를 호출함으로써 원격지 호스트와 설정되어 있던 연결을 종료한다.
도 6은 도 5에서 설명한 IP 기반 어플리케이션의 소켓 제어 관련 프로그램 코드의 일 예를 나타낸 것이다.
참조번호 610은 도 5의 501 단계에서의 socket() 함수의 일 예를 나타낸다.
참조번호 620은 도 5의 503 단계에서의 연결 함수의 일 예를 나타낸다.
도 7은 TCP/UDP Layer에서의 TCP/UDP 세그먼트 전송 과정을 나타낸 흐름도이다.
TCP/UDP Layer(Layer 4)는 701 단계에서 IP 어플리케이션으로부터 데이터를 수신한다.
TCP/UDP Layer는 703 단계에서 전달 받은 데이터에 TCP/UDP 헤더를 추가하여 TCP/UDP 세그먼트를 생성한다. TCP/UDP Layer는 705 단계에서 생성된 세그먼트를 IP Layer(Layer 3)로 전달한다.
도 8은 IP Layer에서의 IP 패킷 전송 과정을 나타낸 흐름도이다.
IP Layer는 801 단계에서 TCP/UDP Layer로부터 TCP/UDP 세그먼트를 수신한다.
IP Layer는 803 단계에서 TCP/UDP 세그먼트에 IP 헤더를 추가하여 IP 패킷을 생성한다.
IP Layer는 805 단계에서 생성된 IP 패킷을 Wi-Fi, LTE(Long Term Evolution) 같은 Layer 2로 전달한다.
도 9는 IP Layer에서의 IP 패킷 수신 과정을 나타낸 흐름도이다.
IP Layer(Layer 3)는 901 단계에서 Wi-Fi, LTE와 같은 Layer 2로부터 원격지 호스트의 IP 패킷을 수신한다. 즉, IP Layer 는 Layer 2로부터 L2 프레임에서 프레임 헤더를 제거하여 IP 패킷을 추출한 것을 수신한다. IP 패킷을 전달 받은 IP Layer는 903 단계에서 IP 헤더를 제거하여 TCP/UDP 세그먼트를 추출하고, 905 단계에서 TCP/UDP Layer로 세그먼트를 전달한다.
도 10은 TCP/UDP Layer에서의 TCP/UDP 세그먼트 수신 과정을 나타낸 흐름도이다.
TCP/UDP Layer는 1001 단계에서 IP Layer로부터 TCP/UDP 세그먼트를 수신한다. IP Layer로부터 TCP/UDP 세그먼트를 전달 받은 TCP/UDP Layer는 1003 단계에서 TCP/UDP 헤더를 제거하여 어플리케이션 데이터를 추출한다. TCP/UDP Layer는 1005 단계에서 IP 어플리케이션으로 어플리케이션 데이터를 전달한다.
라우터는 IP 네트워킹을 지원함으로써, 글로벌 네트워크에서 종단의 단말 간 통신을 가능하게 한다. 하지만 IP 네트워킹에서의 IP 주소는 글로벌 네트워크에서 단말의 고유한 식별자로만 사용하기 때문에 단순 패킷 전송만을 지원할 뿐, 멀티미디어 및 상호교환적인 통신 서비스를 지원하기에 어려움이 있다. 더 나아가 다양한 응용서비스들이 만들어지는 환경에서 IP 주소만으로는 서비스를 인식할 수 없기 때문에 네트워크 안에서 부가 서비스를 제공하는 것이 불가능하다. 또 라우터는 제어 평면과 데이터 평면을 하나의 장치로 통합하고, 라우터 마다 서로 다른 제어 평면 정보를 가지면서 각자 독립적으로 동작하기 때문에, 새로운 네트워킹 프로토콜을 도입하기에 어려운 구조를 가지고 있다. 라우터는 완전 분산 방식의 라우팅 알고리즘과 프로토콜을 사용하기 때문에, 망운영자(Network Operator)가 라우팅 정책을 직접 정의하지 못하는 문제를 가지고 있다. 사용자(User)와 인터넷서비스제공자(Internet Service Provider)도 라우팅 정책에 관여하지 못하며, 네트워크의 정적/동적 정보를 확인할 수도 없다.
종래의 라우터 기술의 문제점을 보완한 기술로 Software Defined Networking(SDN) 기술의 구현물인 오픈 플로우가 있다. 라우터는 완전 분산(Fully distributed)되어 있는 제어 평면 구조를 가지고 있는 반면, 오픈 플로우는 중앙집중화(Centralized)된 제어 평면 구조를 가지고 있다. 또 라우터는 목적지 IP 주소만을 이용하여 포워딩할 물리 포트를 식별하여 패킷을 포워딩하는 반면, 오픈 플로우는 목적지/발신지 MAC 주소, 목적지/발신지 IP 주소, 목적지/발신지 TCP 포트 번호 등 다양한 필드 정보를 이용한 패킷 포워딩을 하며, 뿐만 아니라 컨트롤러로 패킷 포워딩, 패킷 폐기 등을 수행할 수 있다. 이와 같은 오픈 플로우의 기술적 특성은 오픈 플로우 컨트롤러가 오픈 플로우 컨트롤러의 제어를 받는 오픈 플로우 스위치들로 패킷 제어 명령을 내림으로써, 패킷에 대한 플로우를 프로그래머블(Programmable)하게 제어할 수 있게 한다. 또 라우터와 달리, 목적지/발신지 MAC 주소, 목적지/발신지 IP 주소, 목적지/발신지 TCP 포트 번호 등 다양한 필드 정보를 이용하여 패킷을 포워딩하기 때문에, 세밀한 플로우 제어가 가능하다.
종래 SDN/오픈 플로우 기술의 문제점 관련, 오픈 플로우는 라우터보다 세밀하고 프로그래머블한 플로우 제어를 제공하지만, IP 패킷에 대한 포워딩과 플로우 제어에만 한정된다. 그래서 오픈 플로우 또한 라우터와 마찬가지로 IP 프로토콜이 아닌 새로운 네트워크 계층 및 프로토콜을 제공할 수 없다. 구체적 말하자면, 망운영자/인터넷서비스제공자/사용자에 의한 네트워크 기능을 생성하고 수행할 수 있는 네트워크 프로그래머빌리티(Network Programmability)를 제공할 수 없다. 또 오픈 플로우는 망운영자에 의해서 플로우 제어만 가능할 뿐, 인터넷서비스제공자와 사용자에 의한 플로우 제어가 불가능하다. 오픈 플로우는 Rule-Action테이블에 작성되어 있는 플로우에 해당하는 패킷을 처리할 때마다 카운터를 증가시킬 뿐, 네트워크의 정적인 상태와 동적인 상태 정보를 수집할 수 없다. 더 나아가 오픈 플로우 스위치가 다수의 플로우를 제어하기 위해서는 복잡한 심층 패킷 분석(DPI: Deep Packet Inspection)을 요구하기 때문에 패킷 포워딩 측면에서 성능이 저하된다. 오픈 플로우 스위치가 Rule-Action 테이블에 존재하지 않는 다수의 패킷 플로우를 수신할 경우에도 성능 저하 문제를 발생시킨다. Rule-Action테이블에 존재하지 않는 다수의 패킷 플로우를 수신한 오픈 플로우 스위치는 다수의 Packet-In 메시지를 생성하여 오픈 플로우 컨트롤러로 전송한다. 이때 잦은 Packet-In 메시지 전송이 오픈 플로우 스위치와 오픈 플로우 컨트롤러 사이의 인터페이스의 부하를 증가시켜, 오픈 플로우 컨트롤러에서 오픈 플로우 스위치로의 Packet-Out 메시지의 전송 지연이 발생한다. Packet-Out 메시지의 전송 지연은 오픈 플로우 스위치의 Rule-Action 테이블의 갱신의 지연으로 이어짐으로 패킷 포워딩 시간이 증가하게 된다.
먼저, 종래 라우터 기술의 문제점을 정리하면 다음과 같다.
첫째, IP 네트워크 프로토콜만 지원한다. IP는 40년된 프로토콜로서 '생존성'가 목적이다. 따라서, 미디어 및 인터액티브 통신 서비스가 중심인 현재의 인터넷을 성능/기능 면에서 제대로 지원하지 못한다. 이는 IP 외에 새로운 네트워킹 프로토콜의 도입이 어렵기 때문이다.
둘째, 완전 분산 타입 제어 구조로서, 망운영자도 직접 라우팅 정책을 정의 못한다. 따라서, 사용자/인터넷서비스제공자는 라우팅 정책에 관여하지 못하는 것이 당연하며, 사용자/인터넷서비스제공자가 네트워크의 정적/동적 정보도 모르고 본인의 서비스를 구현하게 된다.
셋째, 패킷의 전송만 지원한다. 즉, 단순히 종단간 패킷 전달이 목적으로서, 서비스를 인식하여 부가 서비스를 제공하는 것이 불가능하며, 사용자/인터넷서비스제공자가 자신이 원하는 기능을 직접 망에 넣는 것은 당연하게 불가능하다.
다음으로, 종래 SDN/오픈 플로우의 문제점은 다음과 같다.
첫째, 종래 라우터 기술에서 해결하지 못한 문제로서, 망사업자(망운영자)가 패킷이 전달되는 경로를 결정하는 플로우(Flow)차원의 프로그래머빌리티는 지원하지만, 사용자/인터넷서비스제공자에 대해서 자신의 서비스에 속한 패킷의 경로를 결정하는 플로우(Flow)차원의 프로그래머빌리티는 지원하지 못한다.
둘째, 종래 라우터 기술에서 해결하지 못한 문제로서, 망사업자 및 사용자/인터넷서비스제공자가 자신이 원하는 기능을 네트워크 안에 구현하고 이를 서비스에서 활용하는 기술은 아직도 지원하지 못하고 있다.
셋째, 종래 라우터 기술에서 해결하지 못한 문제로서, 망사업자의 경우 네트워크의 동적/정적 상태를 구체적으로 파악하는 것이 어려우며, 사용자/인터넷서비스제공자의 경우 네트워크의 동적/정적 상태를 구체적으로 파악하는 것이 불가능하다.
넷째, SDN/오픈 플로우 기술의 등장으로 새롭게 발생한 문제로서, 패킷의 헤더 정보를 분석하기 위한 DPI 기능 구현의 부하가 기존 라우터 방식 대비 급격하게 증가한다.
다섯째, SDN/오픈 플로우 기술의 등장으로 새롭게 발생한 문제로서, 중앙집중화 된 SDN 컨트롤러와 오픈 플로우 스위치 간의 인터페이스 부하가 새롭게 발생하며, 네트워크 및 컨트롤러/스위치의 프로세싱 부하를 야기한다.
본 발명은 상기에 기술한 라우터와 SDN/오픈 플로우의 문제를 해결하기 위한 것이다. 본 발명은 망운영자/인터넷서비스제공자/사용자가 네트워크 장치에 새로운 네트워크 기능을 직접 쉽고 빠르게 도입할 수 있도록 하는 함수 기반 네트워크를 제안한다.
본 발명은 네트워크 기능에 대한 함수를 호출할 수 있는 스마트 패킷(SmartPacket)을 사용하여 네트워크 장치의 함수를 실행함으로써, IP 프로토콜뿐만 아니라 새로운 네트워크 기능 및 프로토콜을 제공하고 새로운 네트워크 서비스를 제공할 수 있다.
또한 본 발명은 망운영자/인터넷서비스제공자/사용자가 함수 실행정보를 포함하는 스마트 패킷을 이용하여 네트워크의 정적/동적 정보를 획득하게 하여, 망 관리를 용이하게 하는 것을 가능하게 한다.
도 11은 본 발명의 실시 예에 따른 패킷 생성을 위한 이동 통신 시스템 구조도이다.
도 11을 참조하면, 이동 통신 시스템은 FON 디바이스(Function-Oriented-Network Device, FON Device)(1100), FON 노드(Function-Oriented-Network Node, FON Node)(1130), 및 FON 매니저(Function-Oriented-Network Manager, FON Manager)(1120)를 포함한다.
FON 디바이스(1100)는 함수 이름(Function Name)과 함수 코드(Function Code)를 가지고 있는 함수 테이블(Function Table)을 저장하는 DB(1104)와, 스마트 패킷(1110)을 생성하여 FON 노드로 전송하고, FON 노드로부터 스마트 패킷을 수신할 수 있는 함수 프로세서(Function Processor)(1102)를 포함한다. 스마트 패킷(1110)은 함수 기반의 패킷을 의미하고, IP 주소를 포함하지 않는다.
함수 프로세서(1102)는 FON 노드(1130)로부터 수신한 스마트 패킷(1110)의 함수 호출 필드에 명시되어 있는 함수를 실행할 수 있다. 또한 함수 프로세서(1102)는 FON 매니저(1120)로부터 함수 배포 메시지를 수신하고, 상기 함수 배포 메시지에 포함되어 있는 FON 매니저(1120)의 함수 테이블 정보를 FON 디바이스(1100)의 함수 테이블에 저장 및 업데이트를 수행한다. 함수 프로세서(1102)는 스마트 패킷(1110) 생성 시 DB(1104)에 저장되어 있는 함수 테이블을 이용하여 스마트 패킷(1110)의 검증을 수행할 수 있다.
FON 디바이스에 대한 상세한 설명은 이후 도 15, 도 16의 설명에서 추가로 기술한다.
FON 노드(1130)는 실행 가능한 함수 이름, 함수 코드, 함수 사용 횟수 또는 통계치(Statistics) 정보를 가지고 있는 함수 테이블을 저장하는 DB(1134)와, 스마트 패킷을 수신하고 함수 호출 필드의 정보를 추출하여 함수 이름에 해당하는 함수를 호출하여 실행하는 함수 프로세서(1132)로 구성된다. 함수 프로세서(1132)는 DB(1134)로부터 실행하고자 하는 함수 코드를 추출하여 동적 바인딩을 실시하고, 동적 바인딩된 함수를 실행하는 기능을 수행한다. 또한 함수 프로세서(1132)는 함수 실행 결과를 스마트 패킷의 페이로드에 명시할 수 있고, 다른 FON 디바이스 또는 FON 노드로 스마트 패킷을 전송할 수 있다. 함수 프로세서(1132)는 FON 매니저(1120)로부터 함수 배포 메시지를 수신하고, 상기 함수 배포 메시지에 포함되어 있는 FON 매니저(1120)의 함수 테이블 정보를 FON 노드(1130)의 함수 테이블에 저장 및 업데이트를 수행한다. 또 함수 프로세서(1132)는 FON 매니저로부터 수신한 함수 배포 메시지를 FON 디바이스로 전달함으로써, FON 매니저가 FON 디바이스로 함수 배포 메시지를 전송하는 것을 가능하게 한다. 함수 프로세서(1132)는 FON 디바이스로(1100)부터 함수 테이블에 존재하지 않는 함수 실행을 요청 받았을 때, FON 매니저(1120)로 함수 테이블에 존재하지 않는 함수 코드를 요청하고, FON 매니저(1120)로부터 함수 코드를 수신하는 기능을 수행할 수 있다. 함수 프로세서(1132)는 FON 매니저(1120)로부터 함수 삭제 메시지를 수신하고, 상기 함수 삭제 메시지에 포함되어 있는 함수 이름 정보와 함수 코드 정보를 함수 테이블에서 삭제하고 해당 함수에 대한 동적 바인딩 해제를 수행할 수 있다. 함수 프로세서(1132)는 FON 매니저(1120)로부터 함수 추가 메시지를 수신하고, 상기 함수 추가 메시지에 포함되어 있는 함수 이름 정보와 함수 코드 정보를 함수 테이블에 추가한다. 함수 프로세서(1132)는 DB(1134)에 저장되어 있는 함수 테이블을 관리하며, 사용자별 함수 이용 정보를 FON 매니저(1120)로 보고한다.
FON 매니저(1120)는 실행 가능한 함수 이름과 함수 코드를 가지고 있는 함수 테이블(1124a)과 사용자(Subscriber) 정보 그리고 사용자 별 함수 이용에 따른 과금 정보(Billing Information)를 관리하는 회계 테이블(Accounting Table)(1124b)의 DB(1124)를 포함한다. 또한 FON 매니저(1120)는 함수 테이블(1124a)을 DB(1124)로부터 추출하여 FON 디바이스(1100) 또는 FON 노드(1130)로 전송하는 관리 프로세서(Management Processor)(1122)를 포함한다. 관리 프로세서(1122)는 FON 노드(1130)에서 실행할 수 있는 새로운 함수를 FON 매니저(1120)의 함수 테이블에 추가하고, 함수 추가 메시지를 FON 노드(1130)로 전송함으로써 FON 노드(1130)의 함수 테이블에 함수 이름 정보와 함수 코드 정보를 추가할 수 있다. 관리 프로세서(1122)는 FON 노드(1130)로 함수 삭제 메시지를 전송함으로써, FON 노드(1130)에 저장되어 있는 함수 테이블의 특정 함수 이름 정보와 함수 코드 정보를 삭제할 수 있다.
관리 프로세서(1122)는 FON 노드(1130)로부터 함수 코드 요청을 수신하고, DB(1124)의 함수 테이블(1124a)에서 함수 코드를 추출하여 전달할 수 있다. 관리 프로세서(1122)는 FON 노드(1130)로부터 사용자 별 함수 이용 정보를 수신하여 사용자 별 함수 이용에 대한 과금 정보를 산출하고, 해당 정보를 회계 테이블(1124b)에 저장/관리하는 역할을 수행한다.
관리 프로세서(1122)는 함수 배포 메시지를 FON 노드(1130)로 전송함으로써, FON 매니저(1120)의 함수 테이블을 FON 디바이스(1100) 또는 FON 노드(1130)로 배포하는 역할을 수행한다.
FON 디바이스(1100)는 LTE, WiMAX, Wi-Fi, Bluetooth, ZigBee 등과 같은 무선 전송 기술과 Ethernet 등과 같은 유선 전송 기술을 사용하는 사용자 단말(User Equipment), 센서(Sensor), 데스크탑 컴퓨터, 태블릿(tablet) 컴퓨터, 노트북 등에 적용할 수 있다.
FON 노드(1130)는 라우터, 스위치, Wi-Fi AP(Wi-Fi Access Point), eNB(evolved NodeB), PGW(Packet Data Network Gateway), SGW(Serving Gateway), HeNB(Home evolved NodeB) FGW(Femtocell Gateway) 등에 적용할 수 있으며, 독립적인 장치로 존재하는 것도 가능하다.
FON 매니저(1120)는 MME(Mobility Manager Entity), 오픈 플로우 제어부, SNMP 매니저(Simple Network Management Protocol Manager) 등에 적용할 수 있으며, 독립적인 장치로 존재하는 것도 가능하다.
도 12는 본 발명의 실시 예에 따른 스마트 패킷 구조도이다.
도 12의 스마트 패킷(1200)은 트레일러(Trailer)(1205), 페이로드(Payload)(1207), 함수 호출 필드(1210), 발신지 MAC 헤더(1230), 목적지 MAC 헤더(1240)를 포함한다. 함수 호출 필드(function invocation field)(1210)에는 IPv4/IPv6 주소(이하, "IP 주소"이라 칭함)(1250), TCP/UDP 포트 넘버(1260) 등을 포함할 수 있다. 즉, IP 프로토콜과 스택 구조를 고려하여 IP 네트워크와의 호환성을 제공하기 위해서 함수 호출 필드에 IPv4/IPv6 주소를 선택적으로 포함시킬 수 있다. IP 네트워크가 아닌 경우, IPv4/IPv6 주소를 포함하지 않는다.
함수 호출 필드(1210)는 호출하고자 하는 함수 이름 정보를 포함하며 복수 개의 함수 이름 정보를 포함할 수 있다. 또 호출하고자 하는 함수의 입력 파라미터와 출력 파라미터는 페이로드에 삽입될 수 있다.
도 13 및 도 14는 본 발명이 적용 가능한 네트워크 구성의 예시도이다.
도 13은 본 발명을 활용한 이동 통신 네트워크 구조이고, 도 14는 본 발명을 사용한 유무선 네트워크 구조를 나타낸 것이다.
도 13에서 나타낸 것과 같이, 센서(1312, 1314)와 사용자 단말(1310)에서 FON 디바이스가 적용되어 있다. 센서(1312, 1314)는 Bluetooth, ZigBee와 같은 전송 기술을 이용하여서 펨토셀 기지국(1316)과 통신하며, 사용자 단말(1310)은 LTE와 같은 전송 기술을 이용하여서 펨토셀 기지국(1316) 또는 eNB(1322)와 통신을 한다. 도 13에서의 펨토셀 기지국(1316)은 FON 노드가 적용되어 있고, 예컨대, Bluetooth/ZigBee/LTE/LTE-A 전송 기술을 모두 지원한다. eNB(1322)은 FON 노드가 적용되어 있고, 예컨대, LTE 또는 LTE-A 전송 기술을 지원한다.
FGW(318), eNB(1322), SGW(serving gateway)(1324), PGW(packet data network gateway)(1326)는 FON 노드가 적용되어 있으며, MME(Mobile Mobility Entity)(1320)는 FON 매니저가 적용되어 있는 구조를 가지고 있다.
도 14에서는 Host 1(1410)에 FON 디바이스가 적용되어 있고, Wi-Fi와 같은 무선 전송 기술을 이용하여 Wi-Fi AP(1412)와 통신을 실시한다. Host 2(1424)는 Host 1(1410)과 동일하게 FON 디바이스가 적용되어 있고, Ethernet과 같은 유선 전송 기술을 이용하여 라우터 5(1422)와 통신을 한다. Wi-Fi AP(1412), 라우터 1~5(1414, 1416, 1418, 1420, 1422)는 FON 노드가 적용되어 있으며, FON 매니저(1426)는 상기에 설명한 것과 같이 독립적인 장치로 존재할 수 있다.
도 15는 본 발명의 실시 예에 따른 FON 디바이스의 세부 구조도를 나타낸다.
도 15는 FON 전용 디바이스인 경우의 세부 구조도이다.
도 15를 참조하면, FON 디바이스에는 MAC/PHY Layer(1520) 위에 함수 프로세서(FON processor)와 DB(1514)를 포함하는 FON Layer(Function-Oriented-Network Layer)(1510)가 위치하고, FON Layer(1510) 위에 FON 어플리케이션(Function-Oriented-Network Application)(1500)이 위치한다.
FON 어플리케이션(1500)은 Socket 인터페이스를 이용하여 FON Layer(1510)로 FON 어플리케이션(1500)의 데이터를 전송할 수 있다.
도 16은 본 발명의 실시 예에 따른 FON 디바이스의 다른 세부 구조도를 나타낸다.
도 16은 FON 어플리케이션과 IP 어플리케이션을 동시 지원하는 FON/IP 겸용 디바이스의 구조를 나타낸다.
MAC/PHY Layer(1640) 위에 IP 기반 어플리케이션을 위한 IP Layer(1612)와 TCP/UDP Layer(1610)가 위치한다. IP Layer(1612), TCP/UDP Layer(1610)와 동등한 위치에 FON 프로세서(1632)와 DB(1634)를 포함하는 FON Layer(1630)가 위치하게 된다.
IP 기반 어플리케이션(1600)은 IP 기반 Socket 인터페이스를 이용하여 데이터를 전송한다. 반면에, FON 기반 어플리케이션(1620)은 FON 기반 Socket 인터페이스를 이용하여 데이터를 전송한다. FON 기반 Socket 인터페이스를 IP 기반의 기존 어플리케이션과의 호환성 및 개발 용이성을 위하여, IP 기반 Socket 인터페이스를 수정하여 구현할 수 있다.
FON 디바이스에서의 IP 패킷 생성/전송 및 수신 과정은, 종래의 종단 간 어플리케이션 데이터 통신 방법과 동일하며, 도 5, 6, 7, 8, 9, 10에 나타나 있다. 이는 기존 서비스에 대해서는 호환성 차원에서 동일하게 지원하는 것이다.
도 17은 FON 어플리케이션에서의 스마트 패킷 생성/전송 및 수신 과정을 나타낸 흐름도이다.
FON/IP 겸용 디바이스 또는 FON 전용 디바이스에서 스마트 패킷의 생성/전송 및 수신 시 수행된다. FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 1701 단계에서 socket() 함수를 호출하고, FON 통신을 위한 socket을 생성한다.
FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 1703 단계에서 connection() 함수를 호출하여 FON 노드로 연결을 시도한다.
FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 1705 단계에서 FON 노드로 데이터를 전송할 것인가 FON 노드로부터 데이터를 수신할 것인가를 결정한다.
FON 노드로 데이터를 전송 할 경우, FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 1707 단계에서 spCreate() 함수를 호출하여 스마트 패킷을 생성한다. FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 스마트 패킷이 생성되면, 1709 단계에서 spAdd()함수를 호출하여 FON 노드에서 실행하고자 하는 함수를 스마트 패킷의 함수 호출 필드에 추가한다. 추가적으로 FON 노드에서 실행하고자 하는 함수를 스마트 패킷에 추가할 경우, spAdd()함수를 반복적으로 호출하여 FON 노드에서 실행하고자 하는 함수를 함수 호출 필드에 추가한다. 이와 같이, 여러 개의 함수를 넣어서 실행해 볼 수 있다. 여기서, 여러 가지의 함수의 일 예는 후술할 도 25를 참조하여 설명하기로 한다.
711 단계에서 함수 추가가 완료되면, FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 spTerminate() 함수를 호출하여 스마트 패킷 생성을 완료한다. 스마트 패킷 생성이 완료되면, write() 함수를 호출하여 FON Layer로 스마트 패킷 전송을 요청한다. 계속해서 전송할 데이터가 있을 경우, FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 spCreate(), spAdd(), spTerminate(), write() 함수를 반복적으로 호출하여 FON Layer로 데이터 전송을 요청한다. 1719 단계에서 더 이상 전송할 데이터가 없을 경우, FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 1721 단계에서 close() 함수를 호출함으로써 FON 노드와 설정되어 있던 연결을 종료한다.
1705 단계에서 FON 노드로부터 데이터를 수신하는 것으로 결정할 경우, FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 1717 단계에서 수신된 스마트 패킷의 페이로드를 확인하고, read() 함수를 호출하여 FON Layer에 FON 노드로부터 수신한 스마트 패킷에서 FON 어플리케이션의 데이터 추출 및 수신을 요청한다. 더 이상 데이터 수신을 원하지 않거나 더 이상 수신할 데이터가 없을 경우, FON/IP 겸용 디바이스 또는 FON 전용 디바이스는 close() 함수를 호출함으로써 FON 노드와 설정되어 있던 연결을 종료한다.
도 18은 FON 디바이스에서 FON 기반 어플리케이션의 소켓 제어 관련 프로그램 코드 예시를 나타낸 것이다.
참조번호 1800은 도 17의 1701 단계에서의 socket() 함수의 일 예를 나타낸다.
참조번호 1810은 도 17의 1703 단계에서의 연결 함수의 일 예를 나타낸다.
도 18은 도 6과 비교해 볼 때, 함수 기반(FON)의 소켓이며, 연결 함수에는 도 6에 비해, IP 주소(예컨대, 0.102.111.110)를 기재하였음을 알 수 있다.
도 19는 FON Layer에서의 스마트 패킷 전송 과정을 흐름도이다.
FON Layer는 1901 단계에서 FON 어플리케이션으로부터 스마트 패킷을 수신한다.
FON 어플리케이션으로부터 스마트 패킷을 수신하면, FON Layer는 1903 단계에서 부가적으로 FON Layer의 함수 프로세서가 FON 메시지 검증(Function-Oriented-Network Message Validation) 기능이 활성화 되어 있는지 확인한다. FON 메시지 검증은 FON 디바이스가 생성한 스마트 패킷이 FON 노드에서 오류 없이 네트워크 함수를 실행할 수 있는지를 검사하는 것을 의미한다. FON 검증 메시지 기능이 활성화 되어 있지 않은 경우, FON Layer의 함수 프로세서는 1911 단계에서 스마트 패킷을 구성하고, 1913 단계에서 구성된 스마트 패킷을 Layer 2로 전달한다.
만약, FON 검증 기능이 활성화 되어 있는 경우, FON Layer의 함수 프로세서는 1905 단계에서 FON Layer의 DB에 있는 함수 테이블을 이용하여 스마트 패킷이 FON 노드에서 오류 없이 네트워크 함수를 실행할 수 있는지 검사를 실시한다.
도 20은 FON 디바이스의 DB에 저장되어 있는 함수 테이블의 구조를 나타낸다.
함수 테이블의 구조(2000)는 예컨대, 함수 이름 필드와 함수 코드 필드로 구성된다. 함수 이름 필드에는 FON 노드에서 실행 가능한 함수의 이름을 포함하고, 함수 코드 필드에는 함수 이름에 대한 함수 소스 코드를 포함한다. 이때, FON 디바이스가 FON 노드 또는 다른 FON 디바이스의 요청으로 수행되어야 하는 함수는 소스 코드가 존재하지만, FON 디바이스가 FON 노드 또는 다른 FON 디바이스의 기능을 호출하는 경우는, 함수 이름만 존재하여, FON 메시지 생성 시 올바른 함수 호출인지를 검증하는 용도로 사용된다. FON Layer의 함수 프로세서는 1907 단계에서 FON 어플리케이션이 생성한 스마트 패킷의 함수 호출 필드에 작성되어 있는 함수가 함수 테이블에 존재하는지를 확인한다.
함수 테이블에 스마트 패킷에 작성되어 있는 함수 이름이 존재하지 않을 경우, FON Layer의 함수 프로세서는 1915 단계에서 해당 스마트 패킷을 폐기하고, 1917 단계에서 FON 어플리케이션으로 에러 코드를 리턴한다.
그러나 함수 테이블 안에 스마트 패킷에 작성되어 있는 함수 이름이 존재하는 경우, FON Layer의 함수 프로세서는 1909 단계에서 FON 노드에서 실행 가능한 함수로 판단할 수 있고, 스마트 패킷에 작성되어 있는 다음 함수 이름이 함수 테이블에 존재하는지에 대한 검사를 반복적으로 수행한다. FON Layer의 함수 프로세서는 스마트 패킷에 작성되어 있는 마지막 함수까지 함수 테이블에 존재하면, 11911 단계에서 마지막 함수까지 포함한 스마트 패킷을 생성하고, 1913 단계에서 생성한 스마트 패킷을 Layer 2로 전달한다.
도 21은 FON Layer 에서의 스마트 패킷 수신 과정을 나타낸 흐름도이다.
FON Layer 은 2101 단계에서 Layer 2로부터 스마트 패킷을 수신한다.
FON Layer가 Layer 2부터 스마트 패킷을 전달 받으면, FON Layer의 함수 프로세서는 2103 단계에서 스마트 패킷의 함수 호출 필드를 추출하여 함수 이름을 탐색한다. FON Layer의 함수 프로세서는 2105 단계에서 탐색한 함수 이름이 PacketSend()인가를 판단한다. 만약, 탐색한 함수 이름이 PacketSend()가 아닐 경우, FON Layer의 함수 프로세서는 해당 함수를 실행한다.
그러나 탐색한 함수 이름이 PacketSend()이면, FON Layer의 함수 프로세서는 2107 단계에서 스마트 패킷의 페이로드를 탐색한다. FON Layer의 함수 프로세서는 2111 단계에서 탐색한 페이로드에서 FON 어플리케이션 데이터를 추출하여 FON 어플리케이션으로 전달한다. FON Layer의 함수 프로세서는 2113 단계에서 스마트 패킷의 함수 호출 필드에 작성되어 있는 모든 함수에 대해서 이와 같은 과정을 반복하고, 마지막 함수까지 도달하면 스마트 패킷 수신 과정을 마치게 된다.
도 22는 FON 노드에서의 스마트 패킷 수신 처리 과정을 나타낸 흐름도이다.
FON 노드의 함수 프로세서는 2201 단계에서 FON 디바이스 또는 FON 노드로부터 스마트 패킷을 수신한다.
FON 디바이스 또는 FON 노드로부터 스마트 패킷을 수신하면, FON 노드의 함수 프로세서는 2203 단계에서 수신된 스마트 패킷에서 스마트 패킷의 함수 호출 필드를 추출한다. 그리고 FON 노드의 함수 프로세서는 2205 단계에서 실행할 함수의 이름을 탐색한다. 이때, FON 노드의 함수 프로세서는 2207 단계에서 DB에 저장되어 있는 함수 테이블을 검색한다. FON 노드의 함수 프로세서는 2209 단계에서 함수 테이블로부터 함수 코드를 찾아서 실행한다. 함수 실행 방법은 다양한 방법이 존재할 수 있으며, FON 노드의 함수 프로세서는 동적 바인딩을 이용한 함수 실행을 기본으로 한다. FON 노드의 함수 프로세서는 DB에 저장되어 있는 함수 테이블에 존재하는 함수 코드들을 컴파일하여 실행 파일을 생성하고, 생성된 실행 파일들을 DB에 저장한다. FON 노드의 함수 프로세서는 스마트 패킷의 함수 호출 필드에 명시되어 있는 함수에 대한 실행 파일을 DB로부터 불러와 실행한다. 또 FON 노드의 함수 프로세서는 실행되지 않는 함수의 동적 바인딩을 해제할 수 있다.
이후, FON 노드의 함수 프로세서는 2211 단계에서 실행이 완료된 함수에 대한 통계치를 업데이트하고, 2213 단계에서 모든 함수의 실행을 마쳤는가를 판단한다. 모든 함수의 실행을 마친 경우, FON 노드의 함수 프로세서는 동작을 종료한다. 그러나 모든 함수의 실행을 마치지 않은 경우, FON 노드의 함수 프로세서는 2205 단계로 귀환한다.
도 23은 FON 노드의 DB에 저장되어 있는 함수 테이블의 구조 및 예시도이다.
도 23을 참조하면, 함수 테이블(2300)은 함수 이름 필드, 함수 코드 필드, 통계 필드로 구성된다.
함수 이름 필드에는 FON 노드에서 실행 가능한 함수의 이름을 포함한다.
하고, 함수 코드 필드에는 함수 이름에 대한 함수 소스 코드를 포함한다.
통계 필드는 함수의 호출 횟수를 포함한다.
함수 실행이 완료되면, FON 노드의 함수 프로세서는 실행이 완료된 함수에 대한 함수 테이블의 통계 필드를 업데이트한다. 스마트 패킷에 명시되어 있는 모든 함수에 대해서 이와 같은 과정을 완료하면, FON 노드의 스마트 패킷 수신 처리 과정을 마치게 된다.
추가적으로, FON 노드의 함수 프로세서는 스마트 패킷을 보낸 FON 디바이스를 식별하고, 함수 이용 정보를 FON 매니저로 전송한다. FON 디바이스를 식별하는 방법은 다양한 방법이 존재할 수 있으며, 4G/5G MAC 주소, Wi-Fi 주소, Bluetooth MAC 주소 등과 ISMI(International Mobile Subscriber Identity)와 같은 고유한 사용자 ID를 이용하여서 식별할 수 있다. 또 FON 디바이스가 호출한 함수 이름과 함수 호출 횟수를 산출한다.
사용자 식별 정보와 함수 이용 정보는 도 24에 나타나 있는 함수 이용 정보 보고 메시지를 이용하여 FON 매니저로 전송한다.
도 24는 함수 이용 정보 보고 메시지의 일 예를 도시한 포맷이다.
함수 이용 정보 보고 메시지는 FON 디바이스에서 FON 메니져로 전송되는 메시지이다. 도 24를 통해 예컨대, ISMI를 이용하여 FON 디바이스를 식별함을 알 수 있다. 함수 이용 정보 보고 메시지는 함수 호출 정보를 포함한다. 함수 호출 정보를 추출하여 함수 호출 횟수에 따른 과금 비용을 산출할 수 있다.
도 25는 FON 노드가 지원하는 기본 함수에 대한 리스트의 예시를 나타낸 도면이다.
도 25는 도 17의 1709 단계에서 이용되는 함수의 일 예를 나타낸다.
FON 매니저로부터 함수를 다운 받아 FON 노드의 함수 테이블을 업데이트할 수 있고, 새로운 함수를 추가할 수도 있다. 또 FON 매니저로부터 함수 삭제 메시지를 수신하여, 함수 삭제 메시지에 해당하는 함수를 함수 테이블에서 삭제할 수도 있다. 본 발명에서는 이후 예시된 일부 함수의 구체적 동작을 기술하지만, 추가적인 발명으로 제시할 수 있다.
FON 매니저는 FON 매니저의 DB에 저장되어 있는 함수 테이블을 FON 디바이스과 FON 노드로 배포할 수 있는데, 배포 과정은 다음과 같다.
FON 매니저가 FON 디바이스 또는 FON 노드로 함수 테이블을 배포할 경우, FON 매니저의 관리 프로세서는 DB에 저장되어 있는 함수 테이블을 추출하여 함수 배포 메시지를 생성하여 FON 노드로 생성된 함수 배포 메시지를 전송함으로써, FON 노드로 FON 매니저의 함수 테이블 정보를 배포하게 된다.
패킷 전달할 경우, 이용되는 함수는 PacketSend(),PacketInsertField(),PacketRemoveField(),PacketAddField(),PacketPort()를 포함한다.
PacketSend()는 패킷을 요청한 곳으로 전송하는데 필요한 함수이고, PacketInsertField()는 패킷의 특정 위치(필드)에 요청된 값을 삽입하는데 필요한 함수이고, PacketRemoveField()는 패킷의 특정 위치(필드)의 값을 제거하는데 필요한 함수이고, PacketAddField()는 패킷의 마지막 부분에 요청된 값을 삽입하는데 필요한 함수이고, PacketPort()는 패킷이 전송될 포트 번호(들)을 읽는데 필요한 함수이다.
시스템 정보 조회 시에는 SystemRead() 함수를 이용하고, SystemRead() 함수는 FON 노드의 시스템 정보를 읽어오는데 필요한 함수이다.
사용자 정보 조회 시에는 SubscriberRRead() 함수를 이용하고, SubscriberRRead() 함수는 FON 노드에 접속한 사용자/단말 정보를 읽어오는데 필요한 함수이다.
사용자 저장 공간을 사용시 필요한 함수는 StorageAvailability(),StorageCreate(),StorageRead(),StorageWrite(),StorageRemove() 등을 포함한다.
StorageAvailability() 함수는 FON 노드에 사용자가 요청한 변수가 있는지를 확인하는데 필요한 함수이다.
StorageCreate() 함수는 FON 노드에 사용자가 요청한 변수를 생성하는데 필요한 함수이다.
StorageRead() 함수는 FON 노드에 사용자가 생성한 변수에 값을 읽는데 필요한 함수이다.
StorageWrite() 함수는 FON 노드에 사용자가 생성한 변수에 값을 저장하는데 필요한 함수이다.
StorageRemove() 함수는 FON 노드에 사용자가 요청한 변수를 제거하는데 필요한 함수이다.
사용자 기능 수행시 필요한 함수는 MathRandom() 함수와 MathGetMax() 함수를 포함한다.
MathRandom() 함수는 입력 범위 내에서 Random 함수로 결과 값을 산출하는데 필요한 함수이다.
MathGetMax() 함수는 입력 값을 비교하여 최대값을 리턴하는데 필요한 함수이다.
도 26은 본 발명의 실시 예에 따른 함수 배포 메시지 구조도 및 예시도이다.
함수 배포 메시지 구조도에서 메시지의 목적을 나타내는 명령(Command) 속성은 "Publication"속성값을 갖고, 함수 이름, 함수 코드, 입력 파라미터(input parameter), 출력 파라미터(output parameter) 정보와 배포하고자 하는 장치의 타겟(Target) 정보를 포함한다. 도 26에서의 타켓 정보는 FON 디바이스와 FON 노드가 된다.
도 26에 나타난 바와 같이, 작성된 함수 배포 메시지를 수신한 FON 노드는 Target 속성에 "FON Device"이라는 속성값이 추가로 포함되어 있을 경우, FON 노드와 통신하는 모든 FON 디바이스에게 함수 배포 메시지를 전송함으로써, FON 매니저가 FON 디바이스로 함수 테이블 정보를 배포하게 된다.
FON 매니저는FON 노드에 배포된 함수들 중에서 특정 함수를 삭제하는 명령을 내릴 수 있는데, 함수 삭제 과정은 다음과 같다.
망운영자가 FON 노드의 함수 테이블에 존재하는 함수들 중에서 특정 함수를 삭제하고자 할 때, FON 매니저의 관리 프로세서는 함수 삭제 메시지를 생성하여 FON 노드로 전송함으로써, FON 노드에 존재하는 특정 함수를 삭제하게 된다.
도 27은 본 발명의 실시 예에 따른 함수 삭제 메시지 구조도 및 예시도를 나타낸다.
메시지의 목적을 나타내는 명령 속성은 "Delete"속성값을 갖고, 삭제하고 하자 하는 함수 이름, 함수 코드, 입력 파라미터, 출력 파라미터 정보와 함수 삭제를 수행할 장치의 타겟 정보를 포함한다. 타겟 정보는 예컨대, FON 디바이스와 FON 노드를 포함한다.
FON 매니저는 함수 삭제 메시지를 FON 노드로 전송하고, 이를 수신한 FON 노드가 함수 삭제 메시지에 명시되어 있는 함수 정보를 함수 테이블에서 삭제함으로써, FON 매니저는 FON 노드의 함수 테이블에 존재하는 특정 함수를 삭제하게 된다.
FON 매니저는 망운영자나 3rd-Party 사업자에 의해서 작성된 새로운 함수를 FON 노드로 전송하여 추가할 수 있는데, 새로운 함수 전송 및 추가 과정은 다음과 같다.
망운영자나 3rd-Party 사업자가 FON 노드로 새로운 함수를 추가하고자 할 때, FON 매니저의 관리 프로세서는 함수 추가 메시지를 생성하여 FON 노드로 전송함으로써, FON 노드의 함수 테이블에 새로운 함수를 추가할 수 있다.
도 28은 본 발명의 실시 예에 따른 함수 추가 메시지 구조도 및 예시도를 나타낸다.
메시지의 목적을 나타내는 명령 속성은 "Add"속성값을 갖고, 삭제하고 하자 하는 함수 이름, 함수 코드, 입력 파라미터, 출력 파라미터 정보와 함수 추가를 수행할 장치의 타겟 정보를 포함한다.
타겟 정보는 예컨대, FON 디바이스와 FON 노드를 포함한다.
FON 매니저는 함수 추가 메시지를 FON 노드로 전송하고, 이를 수신한 FON 노드는 함수 추가 메시지에 명시되어 있는 함수 정보를 FON 노드의 함수 테이블에 추가함으로써, FON 매니저는 FON 노드의 함수 테이블에 새로운 함수를 추가하게 된다.
FON 매니저는 FON 노드로부터 함수 이용 정보 메시지를 수신하면, 함수 이용에 따른 과금 정보를 관리하는데, 과금 정보 관리 과정은 다음과 같다.
FON 노드로부터 도 24와 같은 함수 이용 정보 메시지를 수신하면, FON 매니저의 관리 프로세서는 DB에 저장되어 있는 회계 테이블을 관리한다.
도 29는 본 발명의 실시 에에 따른 회계 테이블 구조도를 나타낸다.
FON 매니저의 관리 프로세서는 수신한 함수 이용 정보 보고 메시지에서 FON 노드 정보를 추출하여 사용자를 식별하고, 회계 테이블(2900)의 가입자 속성에 식별된 사용자 정보를 저장한다. 그리고 FON 매니저의 관리 프로세서는 함수 이용 정보 보고 메시지에서 함수 호출 정보를 추출하여 함수 호출 횟수에 따른 과금 비용을 산출한다. 산출된 과금 비용은 회계 테이블의 과금 정보 속성에 저장한다. 이와 같은 과정은 FON 노드로부터 함수 이용 정보 보고 메시지를 수신할 때마다 FON 매니저의 관리 프로세서에 의해 수행하여 사용자 별 네트워크 함수 이용에 따른 과금 정보를 관리하게 된다.
도26, 도 27, 도 28은 본 발명의 예시를 위한 예로서, 다른 언어와 표시로도 구현은 가능하다.
본 발명을 활용한 시나리오의 예로서 본 발명에서는 다음과 같은 4가지 사례를 고려하였으며, 추가적인 함수 제안에 따른 신규 서비스도 가능하다.
첫째, 이기종 망 상에서의 D2D 기반 IoT 통신 환경의 패킷 전송 시나리오다.
도 30은 일반적인 4G/5G 이동통신 네트워크에서의 센서와 사용자 단말 간의 데이터 통신의 예시를 나타낸 시나리오이다.
펨토셀 기지국(3006)이 Bluetooth 전송 기술과 LTE 또는 5G 무선 전송 기술을 지원할 때, 동일한 펨토셀 기지국(3006)에 속해 있는 센서(3002)와 사용자 단말(3004)은 직접 통신을 하지 않고, PGW와 같은 IP Anchor(3008)와 DNS 서버(3010)를 거쳐, 센서(3002)와 사용자 단말(3004)간 IoT(Internet of Things) 통신을 실시한다. 먼저, 사용자 단말(3004)은 DNS 요청 메시지를 펨토셀 기지국(3006), IP Anchor 장치(3008)를 거쳐 DNS 서버(3010)로 전송한다. DNS 서버(3010)는 DNS 응답 메시지를 IP Anchor(3008), 펨토셀 기지국(3006)을 거쳐 사용자 단말(3004)로 전송한다. DNS 요청 및 응답 과정을 통해서, 사용자 단말(3004)은 센서의 IP 주소 정보를 획득하게 된다. 사용자 단말은 획득한 IP 주소를 이용하여 동일한 기지국 내에 있는 센서로 TCP 연결 설정을 시도한다. TCP SYNC 메시지는 펨토셀 기지국(3006), IP Anchor(3008)로 전송되고, IP Anchor(3008)는 센서(3002)가 속해 있는 펨토셀 기지국(3006)으로 TCP SYNC 메시지를 보낸다. 펨토셀 기지국(3006)은 TCP SYNC 메시지를 보낼 센서를 식별하고 Bluetooth 전송 기술을 이용하여 TCP SYNC 메시지를 해당 센서(3002)로 전송한다. TCP SYNC 메시지를 수신한 센서(3002)는 TCP SYNC 메시지에 대한 TCP ACK 메시지를 생성하여 펨토셀 기지국(3006)으로 전송한다. TCP ACK 메시지 수신한 펨토셀 기지국(3006)은 IP Anchor(3008)로 TCP ACK 메시지를 보내고, IP Anchor(3008)는 사용자 단말(3004)이 속해 있는 펨토셀 기지국(3006)으로 TCP ACK 메시지를 전송한다. 펨토셀 기지국(3006)은 TCP ACK 메시지를 보낼 사용자 단말(3004)을 식별하고 LTE 또는 5G 무선 전송 기술을 이용하여 TCP ACK 메시지를 해당 사용자 단말(3004)로 전송한다. 사용자 단말(3004)과 센서의 어플리케이션 데이터, TCP 연결 설정 종료 메시지 등의 전송 과정도, TCP SYNC, TCP ACK 전송 과정과 동일하게 수행된다. 이와 같은 종래의 전송 기술은 이동통신 네트워크 내에 시그널링을 증가시키고, IP Anchor(3008)와 DNS 서버(3010)의 부하와 코어 네트워크의 트래픽을 증가시킨다.
도 31은 도 30의 전송 시나리오를 본 발명을 적용했을 때의 사용자 단말과 센서 간의 데이터 통신 과정을 나타낸 시나리오이다.
사용자 단말은 3101 단계에서 스마트 패킷의 함수 호출 필드에 PacketSend() 함수를 명시하고 센서로 보낼 데이터와 센서의 Bluetooth MAC 주소를 페이로드에 담아 펨토셀 기지국으로 보낸다. 펨토셀 기지국은 FON 노드를 포함하고 있어, 스마트 패킷을 처리할 수 있다. FON 노드를 포함하는 펨토셀 기지국은 페이로드에서 PacketSend() 함수의 입력 파라미터로 사용되는 센서로 보낼 데이터와 센서의 Bluetooth MAC 주소를 추출하여 PacketSend() 함수의 입력 파라미터로 사용하고, 참조번호 3107과 같은 스마트 패킷의 함수 호출 필드에 명시되어 있는 PacketSend() 함수를 실행한다. PacketSend() 함수의 실행 결과로, 펨토셀 기지국이 3103 단계에서 LTE 또는 5G 전송 기술을 이용하여 수신한 사용자 단말의 스마트 패킷을 Bluetooth 전송 기술을 이용하여 센서로 전송한다. 추가적으로 펨토셀 기지국은 사용자 단말로 스마트 패킷이 정상적으로 처리되었음을 알릴 수 있다. 이와 같은 본 발명의 실시 예는 종래의 기술보다 이동 통신 네트워크 내에서 시그널링을 감소시키고, IP Anchor와 DNS 서버 같은 장치의 부하를 분산시키고, 코어 네트워크에 발생하는 트래픽을 감소시킬 수 있다. 또한 본 발명의 실시 예는 무선 링크의 부하를 감소시킴으로써 무선 자원의 사용 효율을 증가시킬 수 있다.
둘째, 종단 간 패킷 전송 경로 정보 수집 시나리오이다.
도 32는 일반적인 종단 간 패킷 전송 경로 정보 수집 예시를 나타낸 것이다. 네트워크 장치는 스위치 또는 라우터 등과 같은 장비로 구성된다.
일반적인 네트워크 구조에서는 DDoS(Distributed Denial of Service) 공격 등에 대비하기 위해서, 보안상의 이유로 네트워크 구조 및 경로 정보를 비공개로 설정한다. 이와 같은 일반적인 네트워크 구조는 사용자 및 망관리자 입장에서 네트워크의 상황과 문제점을 정확하게 파악하기 어렵다는 단점이 있다.
도 33은 본 발명의 실시 예에 따른 종단 간 패킷 전송 경로 정보 수집 시나리오를 나타낸 것이다.
네트워크 장치는 FON 노드로 구성된다. Host 1과 Host 2는 FON 디바이스로 구성된다. FON 노드를 포함하는 네트워크 장치들은 FON 매니저로부터 네트워크 모니터링 함수를 다운로드 받아 동적 바인딩을 실시하고, 사용자 또는 망관리자는 네트워크 모니터링 함수에 대한 실행 정보를 스마트 패킷에 포함시켜 FON 노드로 전송한다. 스마트 패킷을 수신한 FON 노드는 스마트 패킷에 명시되어 있는 네트워크 모니터링 함수를 실행하고, 측정된 네트워크 모니터링 정보를 DB에 저장하고, 사용자 또는 망관리자에게 측정된 네트워크 모니터링 정보를 전송한다. 이와 같은 본 발명의 동작 특성은, 사용자 및 관리 입장에서 네트워크의 상황과 문제점을 정확하게 파악하는 것을 가능하게 한다.
셋째, 생체모방 개미 집단 알고리즘을 이용한 패킷 전송 최적화 시나리오다.
도34는 본 발명의 실시 예에 따른 생체모방 개미 집단 알고리즘을 활용한 패킷 전송 최적화 예시를 나타낸 도면이다.
Host 1과 Host 2는 FON 디바이스로 동작하고, 네트워크 장치들은 FON 노드로 동작한다. 네트워크 장치들은 FON 매니저로부터 생체모방 개미 집단 알고리즘 관련 함수들을 다운로드 받아 동적 바인딩을 수행한다. 이와 같은 상황에서 Host 1는 생체모방 개미 집단 알고리즘을 이용하여Host 1에서 Host 2로의 데이터 전송 경로 중에서 최적화된 전송 경로를 결정하는 함수 실행 정보를 스마트 패킷의 함수 호출 필드에 작성하여 FON 노드가 동작하는 네트워크 장치로 전송한다. 스마트 패킷을 수신한 네트워크 노드는 스마트 패킷의 함수 호출 필드에 명시되어 있는 생체모방 개미 집단 알고리즘 함수들을 실행한다. 함수 실행이 완료되면, 스마트 패킷은 임의의 이웃한 네트워크 장치로 보내지고 해당 네트워크 장치에도 마찬가지로 스마트 패킷에 명시되어 있는 생체모방 개미 집단 알고리즘 함수들을 실행하게 된다. 이와 같은 스마트 패킷 전송 및 생체모방 개미 집단 알고리즘 함수 실행 과정이 반복적으로 수행되어, Host 2에 스마트 패킷이 도달하게 된다. 생체모방 개미 집단 알고리즘 함수들을 명시하고 있는 스마트 패킷이 계속해서 네트워크를 통과하게 되면, FON 노드가 동작하는 네트워크 장치에서는 생체모방 개미 알고리즘에 기반한 최적화된 전송 경로를 결정할 수 있게 된다. 본 발명을 네트워크에 적용할 경우, 다양한 네트워크 프로토콜 및 전송 기술을 도입하여 최적화된 전송 서비스를 제공하는 것이 가능하다.
넷째, 3rd-Party 웹 서비스 또는 미디어 서비스 가속화 시나리오이다.
도 35는 종래의 3rd-Party 웹 서비스 또는 미디어 서비스 가속화 예시도를 나타낸 것이다.
사용자 단말은 웹 페이지를 구성하는 3개의 객체(object)를 서로 다른 HTTP 서버에 요청한다. 사용자 단말은 웹 페이지를 구성하는 3개의 객체에 대해서 HTTP 요청 메시지를 생성하여 기지국(BS)으로 전송한다. 사용자 단말의 HTTP 요청 메시지를 수신한 기지국은 서로 다른 HTTP 서버로 HTTP 요청 메시지를 전송한다. HTTP 요청 메시지는 이동 통신 네트워크를 거쳐 3rd-Party의 HTTP 서버 1, HTTP 서버 2, HTTP 서버 3에 도달하게 된다. HTTP 요청 메시지를 수신한 3rd-Party의 HTTP 서버 1, HTTP 서버 2, HTTP 서버 3은 웹 페이지를 구성하는 객체에 대한 HTTP 응답 메시지를 생성하여 사용자 단말로 전송한다. 3rd-Party의 HTTP 서버 1, HTTP 서버 2, HTTP 서버 3에서 전송된 HTTP 응답 메시지는 이동통신 네트워크를 거쳐 사용자 단말이 속한 기지국으로 전송되고, 기지국은 사용자 단말로 HTTP 응답 메시지를 전송하게 된다. 이와 같은 종래 기술의 웹 서비스 가속 방식은 인터넷에 3rd-Party 웹 서버를 배치하기 보다는 이동통신 네트워크 내에 웹 서버를 배치함으로써 이동통신 내에 있는 사용자 단말에게 가속화된 웹 서비스를 제공하는 방식이다. 이는 물리적으로 사용자 단말과 3rd-Party의 웹 서버 거리를 줄임으로써, 웹 서비스를 가속화할 뿐, 웹 서비스 자체를 가속화 하지는 못한다.
도 36은 본 발명의 실시 예에 따른 3rd-Party 웹 서비스 또는 미디어 서비스 가속화 예시도를 나타낸다.
사용자 단말은 FON 디바이스로 동작하고, 기지국은 FON 노드로 동작하고 있다.
기지국(FON 노드)는 FON 매니저로부터 3rd-Party가 제공한 웹 서비스 및 전송 최적화 기술을 구현한 함수를 다운로드 받아 DB에 저장하고 동적 바인딩하여 함수가 실행될 수 있도록 준비한다.
사용자 단말(FON 디바이스)는 3rd-Party의 웹 페이지를 요청하는 스마트 패킷을 생성하여 기지국으로 전송한다. 이때, 웹 페이지를 구성하는 서로 다른 3개의 객체에 대한 3개의 스마트 패킷을 생성하여 전송하는 것이 아니라, 1개의 스마트 패킷에 3개의 객체를 요청하도록 함수 호출 필드를 작성하여 기지국으로 전송한다. 상기 스마트 패킷을 수신한 기지국은 스마트 패킷에 명시되어 있는 함수를 실행하여 웹 페이지를 구성하는 3개의 객체에 대한 HTTP 요청 메시지를 생성하여 3rd-Party의 HTTP 서버 1, HTTP 서버 2, HTTP 서버 3로 전송한다. 또 기지국이 수신한 스마트 패킷에 코어 네트워크에서의 최적화된 전송 함수를 포함하고 있다면, 3rd-Party의 HTTP 서버로 HTTP 요청 메시지를 전송할 수 있게 된다. HTTP 요청 메시지를 수신한 3rd-Party의 HTTP 서버는 웹 페이지를 구성하는 객체에 대해서 HTTP 응답 메시지를 생성하여 기지국으로 전송한다. 3rd-Party의 HTTP 서버로부터 HTTP 응답 메시지를 수신한 기지국은 HTTP 응답 메시지에 포함되어 있는 객체가 멀티미디어 컨텐츠라면, 사용자 단말의 하드웨어 특성에 맞도록 컨텐츠를 압축하거나 크기를 줄이는 등의 컨텐츠 최적화를 수행하여 사용자 단말로 전송한다.
이와 같이, 본 발명의 실시 예는 무선 구간에서 전송되는 메시지의 개수를 줄여 무선 구간에서의 지연을 최소화하고, 3rd-Party의 컨텐츠를 최적화할 수 있으며, 코어 네트워크 등의 유선 구간에서 전송을 최적화함으로써, 3rd-Party 웹 서비스 또는 미디어 서비스를 가속화는 것이 가능하다.
본 발명의 효과는 다음과 같다.
첫째, IP 네트워크 프로토콜 외에 새로운 프로토콜의 도입이 가능하다. 네트워크에 새로운 네트워크 프로토콜의 기능을 함수로 구현하여 FON 노드들에 배포하고, 스마트 패킷을 통해서 기능을 호출함으로써, 망운영자/사용자/인터넷서비스제공자가 자신만의 새로운 네트워크 프로토콜을 만들고 망에 도입하는 것이 가능하다.
둘째, 망운영자와 사용자/인터넷서비스제공자가 직접 라우팅 정책을 정의할 수 있다. 직접 본인이 구현한 함수에 의하여 자신이 결정한 패킷 경로로 트래픽을 전송하는 것을 지원한다.
셋째, 패킷의 전송 외에 패킷이 요구하는 부가 기능을 FON 노드에서 지원할 수 있다.
종래 SDN/오픈 플로우 의 문제점에 대한 본 기술의 해결 사항은 다음과 같다.
첫째, 종래 라우터 기술에서 해결하지 못한 문제의 해결로서, 망사업자(망운영자) 및 사용자/인터넷서비스제공자가 패킷이 전달되는 경로를 결정하는 플로우차원의 프로그래머빌리티를 지원한다. 앞서 종래 라우터의 기술 문제점 해결에서 언급했듯이, 네트워크에 새로운 네트워크 프로토콜의 기능을 함수로 구현하여 FON 노드들에 배포하고, 스마트 패킷을 통해서 기능을 호출함으로써, 망운영자/사용자/인터넷서비스제공자가 자신만의 새로운 네트워크 프로토콜을 만들고 망에 도입하는 것이 가능하다. 또한, 직접 본인이 구현한 함수에 의하여 자신이 결정한 패킷 경로로 트래픽을 전송하는 것을 지원한다.
둘째. 종래 라우터 기술에서 해결하지 못한 문제의 해결로서, 망사업자 및 사용자/인터넷서비스제공자가 자신이 원하는 기능을 네트워크 안에 구현하고 이를 서비스에서 활용하는 기술이 가능하다. 앞서 종래 라우터의 기술 문제점 해결에서 언급했듯이, 패킷의 전송 외에 패킷이 요구하는 부가 기능을 FON 노드에서 지원할 수 있다.
셋째, 종래 라우터 기술에서 해결하지 못한 문제의 해결로서, 망사업자 및 사용자/인터넷서비스제공자가 네트워크의 동적/정적 상태를 구체적으로 파악하는 것이 가능하다. 본 기술의 활용 시나리오에서 나타난 것처럼, FON 노드의 부가 기능 구현을 통해서 네트워크의 동적/정적 상태를 스마트 패킷을 통해서 파악하는 것이 가능하다.
넷째, SDN/오픈 플로우 기술의 등장으로 새롭게 발생한 문제의 해결로서, 패킷의 헤더 정보를 분석하기 위한 DPI(Deep Packet Inspection) 기능의 구현이 단순화된다. 복잡한 패킷 구조를 일일이 분석하는 부하가 필요하지 않고, 단순하게 함수 호출 부분만 분석하는 수준으로 복잡도가 낮아진다.
다섯째, SDN/오픈 플로우 기술의 등장으로 새롭게 발생한 문제의 해결로서, 중앙집중화 된 SDN 컨트롤러와 오픈 플로우 스위치 간의 인터페이스 부하가 발생하지 않는다. 기존 SDN/오픈 플로우의 경우 컨트롤러만이 지능적인 처리를 하지만, FON 노드에서는 자체적으로 지능적인 패킷 처리가 가능하기에 FON 노드 매니저와의 인터페이스 부하가 SDN 대비 크지 않다.
한편 본 발명의 일 실시 예에 따른 이동 통신 시스템에서 패킷 생성 방법 및 장치 는 하드웨어, 소프트웨어 또는 하드웨어 및 소프트웨어의 조합의 형태로 실현 가능하다는 것을 알 수 있을 것이다. 이러한 임의의 소프트웨어는 예를 들어, 삭제 가능 또는 재기록 가능 여부와 상관없이, ROM 등의 저장 장치와 같은 휘발성 또는 비휘발성 저장 장치, 또는 예를 들어, RAM, 메모리 칩, 장치 또는 집적 회로와 같은 메모리, 또는 예를 들어 CD, DVD, 자기 디스크 또는 자기 테이프 등과 같은 광학 또는 자기적으로 기록 가능함과 동시에 기계(예를 들어, 컴퓨터)로 읽을 수 있는 저장 매체에 저장될 수 있다. 본 발명의 일 실시 예에 따른 이동 통신 시스템에서 패킷 생성 방법은 제어부 및 메모리를 포함하는 컴퓨터 또는 휴대 단말에 의해 구현될 수 있고, 상기 메모리는 본 발명의 실시 예들을 구현하는 지시들을 포함하는 프로그램 또는 프로그램들을 저장하기에 적합한 기계로 읽을 수 있는 저장 매체의 한 예임을 알 수 있을 것이다.
따라서, 본 발명은 본 명세서의 임의의 청구항에 기재된 장치 또는 방법을 구현하기 위한 코드를 포함하는 프로그램 및 이러한 프로그램을 저장하는 기계(컴퓨터 등)로 읽을 수 있는 저장 매체를 포함한다. 또한, 이러한 프로그램은 유선 또는 무선 연결을 통해 전달되는 통신 신호와 같은 임의의 매체를 통해 전자적으로 이송될 수 있고, 본 발명은 이와 균등한 것을 적절하게 포함한다.
또한 본 발명의 실시 예에 따른 이동 통신 시스템에서 패킷 생성 장치는 유선 또는 무선으로 연결되는 프로그램 제공 장치로부터 상기 프로그램을 수신하여 저장할 수 있다. 상기 프로그램 제공 장치는 상기 프로그램 처리 장치가 기 설정된 이동 통신 시스템에서 패킷 생성 방법을 수행하도록 하는 지시들을 포함하는 프로그램, 이동 통신 시스템에서 패킷 생성 방법에 필요한 정보 등을 저장하기 위한 메모리와, 상기 그래픽 처리 장치와의 유선 또는 무선 통신을 수행하기 위한 통신부와, 상기 그래픽 처리 장치의 요청 또는 자동으로 해당 프로그램을 상기 송수신 장치로 전송하는 제어부를 포함할 수 있다.
한편 본 발명의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 발명의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 발명의 범위는 설명된 실시 예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 이동 통신 시스템에서의 디바이스에서 패킷 생성 방법에 있어서,
    네트워크가 제공하는 기능을 포함하는, 함수 기반의 패킷을 생성하는 과정; 및
    상기 패킷을 타켓 노드로 전송하는 과정을 포함하고,
    상기 패킷은 IP(internet protocol) 주소가 제외됨을 특징으로 하는 디바이스에서 패킷 생성 방법.
  2. 제1항에 있어서,
    상기 패킷은 함수 이름 및 파라미터를 포함하는 함수 호출 필드를 포함함을 특징으로 하는 디바이스에서 패킷 생성 방법.
  3. 제2항에 있어서,
    상기 함수 이름은, 패킷 전달 관련 함수, 시스템 정보 조회 함수, 사용자 정보 조회 함수, 사용자 저장 공간 사용 관련 함수, 사업자 기능 수행 관련 함수 중 적어도 하나를 포함함을 특징으로 하는 디바이스에서 패킷 생성 방법.
  4. 제2항에 있어서,
    상기 파라미터는 호출하고자 하는 함수의 입력 파라미터 및 출력 파라미터를 포함함을 특징으로 하는 디바이스에서 패킷 생성 방법.
  5. 제1항에 있어서,
    함수 이름과 함수 코드를 포함하는 함수 테이블을 저장하는 과정을 더 포함함을 특징으로 하는 디바이스에서 패킷 생성 방법.
  6. 제1항에 있어서,
    함수 이름과 함수 코드를 포함하는 함수 테이블을 저장하는 과정을 더 포함함을 특징으로 하는 디바이스에서 패킷 생성 방법.
  7. 이동 통신 시스템에서의 네트워크에서 패킷 수신 방법에 있어서,
    네트워크가 제공하는 기능을 포함하는, 함수 기반의 패킷을 수신하는 과정;
    상기 패킷의 함수 테이블을 이용하여 함수를 확인하는 과정;
    해당 함수를 실행하는 과정을 포함하고,
    상기 패킷은 IP(internet protocol) 주소가 제외됨을 특징으로 하는 네트워크에서 패킷 수신 방법.
  8. 제7항에 있어서,
    상기 패킷은 함수 이름 및 파라미터를 포함하는 함수 호출 필드를 포함함을 특징으로 하는 네트워크에서 패킷 수신 방법.
  9. 제8항에 있어서,
    상기 함수 이름은,
    패킷 전달 관련 함수, 시스템 정보 조회 함수, 사용자 정보 조회 함수, 사용자 저장 공간 사용 관련 함수, 사업자 기능 수행 관련 함수 중 적어도 하나를 포함함을 특징으로 하는 네트워크에서 패킷 수신 방법.
  10. 제8항에 있어서,
    상기 파라미터는 호출하고자 하는 함수의 입력 파라미터 및 출력 파라미터를 포함함을 특징으로 하는 네트워크에서 패킷 수신 방법.
  11. 제7항에 있어서,
    함수 이름과 함수 코드를 포함하는 함수 테이블을 저장하는 과정을 더 포함함을 특징으로 하는 네트워크에서 패킷 수신 방법.
  12. 이동 통신 시스템에서의 네트워크에서 패킷 수신 장치에 있어서,
    네트워크가 제공하는 기능을 포함하는, 함수 기반의 패킷을 수신하는 수신부; 및
    상기 패킷의 함수 테이블을 이용하여 함수를 확인하고, 해당 함수를 실행하는 제어부를 포함하고,
    상기 패킷은 IP(internet protocol) 주소가 제외됨을 특징으로 하는 네트워크에서 패킷 수신 장치.
  13. 제12항에 있어서,
    상기 패킷은 함수 이름 및 파라미터를 포함하는 함수 호출 필드를 포함함을 특징으로 하는 네트워크에서 패킷 수신 장치.
  14. 제13항에 있어서,
    상기 함수 이름은, 패킷 전달 관련 함수, 시스템 정보 조회 함수, 사용자 정보 조회 함수, 사용자 저장 공간 사용 관련 함수, 사업자 기능 수행 관련 함수 중 적어도 하나를 포함함을 특징으로 하는 네트워크에서 패킷 수신 장치.
  15. 제13항에 있어서,
    상기 파라미터는 호출하고자 하는 함수의 입력 파라미터 및 출력 파라미터를 포함함을 특징으로 하는 네트워크에서 패킷 수신 장치.
PCT/KR2016/002714 2015-03-17 2016-03-17 이동 통신 시스템에서 패킷 생성 방법 및 장치 WO2016148527A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/558,989 US10645613B2 (en) 2015-03-17 2016-03-17 Method and apparatus for generating packet in mobile communication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020150036581A KR102271871B1 (ko) 2015-03-17 2015-03-17 이동 통신 시스템에서 패킷 생성 방법 및 장치
KR10-2015-0036581 2015-03-17

Publications (1)

Publication Number Publication Date
WO2016148527A1 true WO2016148527A1 (ko) 2016-09-22

Family

ID=56919912

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/002714 WO2016148527A1 (ko) 2015-03-17 2016-03-17 이동 통신 시스템에서 패킷 생성 방법 및 장치

Country Status (3)

Country Link
US (1) US10645613B2 (ko)
KR (1) KR102271871B1 (ko)
WO (1) WO2016148527A1 (ko)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10095878B2 (en) * 2015-06-02 2018-10-09 ALTR Solutions, Inc. Internal controls engine and reporting of events generated by a network or associated applications
US9881176B2 (en) 2015-06-02 2018-01-30 ALTR Solutions, Inc. Fragmenting data for the purposes of persistent storage across multiple immutable data structures
US10193696B2 (en) 2015-06-02 2019-01-29 ALTR Solutions, Inc. Using a tree structure to segment and distribute records across one or more decentralized, acylic graphs of cryptographic hash pointers
CN108513348B (zh) * 2017-02-28 2021-01-12 大唐高鸿信息通信(义乌)有限公司 5g网络的非正交多址接入的蚁群功率分配优化算法
KR102324361B1 (ko) * 2017-05-29 2021-11-11 한국전자통신연구원 집단 지능 기반 악의적 기기 탐지 장치 및 방법
CN112543151B (zh) * 2020-11-25 2022-10-04 中移（杭州）信息技术有限公司 Sdn控制器部署方法、装置、电子设备和存储介质
WO2022132129A1 (en) * 2020-12-15 2022-06-23 Funai Electric Co., Ltd. Collaborative iot device anomaly detection

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080076464A (ko) * 2007-02-16 2008-08-20 삼성전자주식회사 분산 구조 라우팅 시스템에서 아이피 버전 식스 링크 로컬주소 지원 장치 및 방법
KR20080095668A (ko) * 2007-04-25 2008-10-29 포스데이타 주식회사 휴대 인터넷 시스템의 서비스 품질 보장 장치 및 방법
KR20090028613A (ko) * 2006-06-07 2009-03-18 콸콤 인코포레이티드 무선 통신을 위한 효율적 어드레스 방법들, 컴퓨터로 읽을 수 있는 매체 및 장치
US7512088B1 (en) * 2002-07-12 2009-03-31 Cisco Technology, Inc. Routing data packets to a mobile node
EP2725763A1 (en) * 2012-10-24 2014-04-30 Alcatel Lucent Apparatus, method and computer program for relaying payload data between two network nodes

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030152065A1 (en) * 2002-02-08 2003-08-14 Institute For Information Industry Integrated IP network telephone distributor with switching and routing functions
CN103226950A (zh) * 2012-01-29 2013-07-31 特克特朗尼克公司 电信网络中的语音处理
US8832820B2 (en) 2012-06-25 2014-09-09 International Business Machines Corporation Isolation and security hardening among workloads in a multi-tenant networked environment
US20150249548A1 (en) * 2014-02-28 2015-09-03 Tyco Fire & Security Gmbh Establishing Links Between Sub-Nets

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512088B1 (en) * 2002-07-12 2009-03-31 Cisco Technology, Inc. Routing data packets to a mobile node
KR20090028613A (ko) * 2006-06-07 2009-03-18 콸콤 인코포레이티드 무선 통신을 위한 효율적 어드레스 방법들, 컴퓨터로 읽을 수 있는 매체 및 장치
KR20080076464A (ko) * 2007-02-16 2008-08-20 삼성전자주식회사 분산 구조 라우팅 시스템에서 아이피 버전 식스 링크 로컬주소 지원 장치 및 방법
KR20080095668A (ko) * 2007-04-25 2008-10-29 포스데이타 주식회사 휴대 인터넷 시스템의 서비스 품질 보장 장치 및 방법
EP2725763A1 (en) * 2012-10-24 2014-04-30 Alcatel Lucent Apparatus, method and computer program for relaying payload data between two network nodes

Also Published As

Publication number Publication date
KR20160111668A (ko) 2016-09-27
KR102271871B1 (ko) 2021-07-01
US10645613B2 (en) 2020-05-05
US20180249371A1 (en) 2018-08-30

Similar Documents

Publication Publication Date Title
WO2016148527A1 (ko) 이동 통신 시스템에서 패킷 생성 방법 및 장치
WO2021010693A1 (en) Method and apparatus for identifying user in ran communication system
WO2018110952A2 (en) Apparatus and method for controlling data flow in wireless communication system
WO2021060840A1 (en) Method and apparatus for detecting service and analyzing service characteristic using nwdaf in mobile communication system
WO2017164674A1 (ko) 기지국에서 연결 모드 변경 방법 및 기지국과, 사용자기기에서 연결 모드 변경 방법 및 사용자기기
WO2021054747A1 (ko) 무선 통신 시스템에서 psa-upf 재배치를 위한 장치 및 방법
WO2020204474A1 (ko) 무선 통신 시스템에서 에지 컴퓨팅 서비스를 제공하기 위한 장치 및 방법
WO2021086131A1 (en) Device and method for fronthaul transmission in wireless communication system
WO2016021890A1 (en) Signalling in dual connectivity mobile communication networks
WO2019194486A1 (en) Method and apparatus for discarding buffered data while keeping connection in cp-up separation
WO2020032769A1 (ko) 무선 통신 시스템에서 네트워크 트래픽 관리 방법 및 장치
WO2016108680A1 (ko) 무선 통신 시스템에서 d2d 동작 수행 방법 및 상기 방법을 이용하는 단말
WO2021091232A1 (ko) 이동통신 시스템에서 어플리케이션 서버의 정보 제공 장치 및 방법
WO2018221942A1 (ko) 상향링크 서비스 품질을 관리하는 방법 및 상기 방법을 수행하는 기지국
WO2021049782A1 (en) Method and apparatus for providing policy of user equipment in wireless communication system
WO2021091270A1 (en) Method and apparatus for selecting network slices in wireless communication system
WO2019160300A1 (ko) 복수의 네트워크 시스템에 접속할 수 있는 단말에 sm 신호를 전송하는 방법
WO2021141335A1 (en) Apparatus and method for controlling network slice data rate in wireless communication system
WO2018038412A1 (ko) 차세대 네트워크에서 복수의 액세스를 통해 접속을 수행하는 방법 및 사용자 장치
WO2016208919A1 (ko) 이동 통신 네트워크에서 신호를 송/수신하는 장치 및 방법
WO2021235880A1 (ko) 무선 통신 시스템에서 단말로 지역 데이터 네트워크 정보를 제공하기 위한 방법 및 장치
WO2020138981A1 (en) Method and apparatus for providing rule information in wireless communication system
WO2020013468A1 (ko) Ladn 영역에 대한 정보가 변경된 경우 단말이 pdu 세션 설립 요청을 수행하는 방법
WO2021172874A1 (en) Method and apparatus for executing virtualized network function
WO2023075214A1 (en) Method and apparatus for supporting edge computing service for roaming ue in wireless communication system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16765283

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15558989

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16765283

Country of ref document: EP

Kind code of ref document: A1