Abstract:
A method for control an access network node which is comprising of central office (CO) and more than one customer premises equipment (CPE), provides a single management interface in the CO to a software defined network management system, that utilizes a software defined network protocol, the interface allows the software defined network management system to configure an user flow in the access network node by assigning a network node interface resides in the CO which interconnects to a core network and an user network node interface resides in the CPE which interconnects to a user terminal and a required user data forwarding function for the flow, the access network node maintains its own forwarding resources and it determines available resources required for the forwarding request, configures the CO and/or the CPE with a protocol translation which adapts the software defined protocol with the legacy protocol when the CO and/or the CPE works with the legacy protocol.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority benefit of U.S. Provisional Application No. 62/032,578, filed on Aug. 3, 2014 by inventor Toshihiko Kusano 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates to a network virtualization method for a telecommunication network system which comprise of SDN non-native devices to manage them seamlessly among with SDN native devices from a SDN Management System. 
         [0003]    The present invention is particularity suitable for an access network system which is comprised from Central Office (CO) and Customer Premises Equipment (CPE). 
       BACKGROUND OF THE INVENTION 
       [0004]    Recently, Software Defined Network (SDN) has been widely recognized as the next generation network management scheme in the packetized data communication era. Current SDN defines SDN native control message and protocol, OpenFlow is the well-known standard for the control message, but it may not be true to determine the protocol is the only choice applicable to the SDN concept. Hereinafter use “SDN control message” as a generalized protocol name which can be used for SDN. 
         [0005]    In the origin of the OpenFlow, it has been assumed to control a standalone OpenFlow device which will replace today&#39;s Layer two (2) switches (L2SW) and routers; all of them are not in a form of multi node system. Compare with the L2SWs and routers, access network system is comprised of CO and CPEs and they are tightly coupled in its configuration. For example, Passive Optical Network (PON) which is used for Fiber To The X (FTTX, X stands various types of delivery method) services consists from Optical Line Terminator (OLT) as CO device and Optical Network Unit (ONU) as CPE device. The OLT controls the ONUs with a specific control method and protocol, which is known as Multi-Point Control Protocol (MPCP) and Operation Administration and Maintenance (OAM) protocol. If operator wants to apply the current OpenFlow control to those devices, both the OLT and ONU need to be an OpenFlow native device. 
         [0006]    While network operator deployed the access system in large, it is a significant disadvantage for operators who wants to use OpenFlow because all standalone device needs to be a standalone SDN native device. The situation will enforce operators to replace the whole access network system if they plan to manage devices under integrated SDN management. Current resolution requests to replace whole CPEs in the customer sites; such construction will cause a severe service disruption. On the other hand, when operator decides to manage using SDN across the network system includes the access system, it is essential to manage every system in an integrated manner for maximize the benefit from the view of OPEX and CAPEX for the network management. 
         [0007]    From this background, it is proposed to virtualize an access network system itself as a single SDN native node, and thereinafter, the SDN Management System can control and manage the access system without a necessity to aware the type of device but control and manage them as a part of the SDN device. 
       SUMMARY OF THE INVENTION 
       [0008]    It is therefore an object of the present invention is to support virtualized SDN adapted access network which can be controlled by SDN Management System as same as a SDN native device. 
         [0009]    According to the present invention, there is provided a telecommunication network system comprising of; a SDN Management System, Virtual Access Node comprise a Central Office (CO) and a Customer Premises Equipment (CPE), user terminals, core data network, and virtualized access User Network Interface (UNI) and virtualized access Network Node Interface (NNI). Data channels which carry user data packets across the network; i.e., among access network system (between CO and CPE), user terminals, and core data network. Virtualized access UNI and virtualized access NNI interfaces between use terminal and core data network respectively. From the SDN Management System, it can control the Virtual Access Node as a single device which has two interfaces for downstream side (virtualized access UNI) and upstream side (virtualized access NNI), and control the virtual device without knowing its internal structure. 
         [0010]    The present invention consists from; a) a concept of a Virtual Access Node which comprises SDN non-native CO and CPEs, b) a mechanism to convert multi-device structure of an access network into single virtualized node, and c) method to co-exist SDN non-native CO/CPEs and SDN native CO/CPEs for potential configuration in the future. 
         [0011]    Following previously filed two patents have supportive role to the current patent; PCT/IL13/050947 entitled “TELECOMMUNICATION NETWORK NODE SUPPORTING HYBRID MANAGEMENT USING A HARDWARE ABSTRACTION AND MANAGEMENT PROTOCOL CROSS-CONNECT FUNCTION” claims the control message cross-connect function in the CO to deliver the OpenFlow message to legacy CPEs, and U.S. patent Ser. No. 14/256,011 entitled “ARCHITECTURE FOR AN ACCESS NETWORK SYSTEM MANAGEMENT PROTOCOL CONTROL UNDER HETEROGENEOUS NETWORK MANAGEMENT ENVIRONMENT” claims message bridging and encapsulation function which is an element to realize the current patent. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    The present invention will be described in further details with reference to the accompanying drawings, in which; 
           [0013]      FIG. 1  is a block diagram of an access network system incorporating with CO and CPE, and the Virtual Access Node with the concept of virtualized UNI and NNI of the present invention; 
           [0014]      FIG. 2  is a schematic block diagram of an access network system for a CO and a CPE, that the CO deploys SDN Agent, Resource Manager with two databases for Capability List and Serving Resource List, Protocol Translator, Message Parser for communicating between CO and CPE through a control channel between CO and CPE; 
           [0015]      FIG. 3  is a logical representation of a database for the Capability List which shows available functions in the CO and the CPE respectively; 
           [0016]      FIG. 4  is a logical representation of a database for the Serving Resource List, which shows a usage status of each resource allocated to complete the requested configuration from SDN Management System; 
           [0017]      FIG. 5  is a block diagram of an access network system with SDN native CPE; 
           [0018]      FIG. 6  is a block diagram of an access network system both with SDN non-native CPE and SDN native CPE. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0019]    In  FIG. 1 , a Virtual Access Node  120  which comprises of CO  101  and CPEs  110 . The CO  101  of the Virtual Access Node  120  connects to SDN Management System  130  through a communication network. SDN Management System  130  controls the Virtual Access Node  120  as a single network node and the SDN Management System  120  understands virtualized access UNI  111  and virtualized access NNI  112  as the interface points of the virtualized access node  120  to inter-connecting with outside of the system such as user terminals  140  and core data network  141  to send and receive user data packets for the service data transmission. The SDN Management System  130  can control multiple virtualized access nodes through the communication network. 
         [0020]      FIG. 2  describes function blocks in the Virtual Access Node  220  of the current patent. A SDN Agent  202  in the CO  201  interacts with SDN Management System  230  to send and receive SDN control messages. A Resource Manager  203  manages existing feature set in the CO  201  and CPE  210 , it is outside of the patent though it is a general understanding that the existing feature set can be confirmed by knowing manufacture and product number etc., that are regularly be able to collect via digital data as an attribute of a managed object. A Resource Manager  203  allocates appropriate resources to complete the flow forwarding request received from a SDN Management System  230  via SDN Agent  202  and it updates the usage status after made an allocation. A Protocol Translator  206  translates a SDN control message to a SDN no-native (legacy) protocol used in the Virtual Access Node  220 , hence vast majority of today&#39;s deployed access system supports only the legacy protocol then translate a SDN control message to a corresponding legacy message is mandatory. A message parser  207  forwards the legacy protocol translated from SDN control messages to the corresponding flow forwarding resources (hardware resources) in the CO  201  and CPE  210 . If the request needs to be forwarded to CPE  210 , then the message will be passed to the send/receive socket to transfer via control channel  209  to the target CPE  210 . By receiving the message through control channel at CPE  210 , the message is passed to the processor  211  through message parser  212  in the CPE  210  and the processor  210  determines the required actions to control its flow forwarding resources  213 . 
         [0021]    The DN Management System  230  sends a configuration request to the Virtual Access Node  220 , the message is comprised of following elements as a minimum set of attributes but not limited; 
         [0022]    Virtualized access UNI 
         [0023]    Virtualized access NNI 
         [0024]    Forwarding action(s) requested 
         [0025]    Forwarding action(s) will be varied by system however it is assumed that following types of operation will be generally available; 
         [0026]    Packet reception/discarding rule 
         [0027]    VLAN manipulation (add/drop/transparent/swap etc.) 
         [0028]    Queue configuration 
         [0029]    Rate control, shaping and policing 
         [0030]    A SDN Agent  202  in the CO  201  receives the request from SDN Management System  230 . Since the message designates the virtualized access UNI  111  in  FIG. 1  and virtualized access NNI  112  in  FIG. 1  as the Virtual Access Node  220  of its termination points and the action does not designate which resource (i.e., CO  201  and/or CPE  210  etc.) then the message is needed to be broken into pieces to be understood by the access network system  220 . To resolve which resource(s) to be served for the requested action(s), the SDN Agent  202  passes the message to the Resource Manager  203  to request to allocate appropriate resource(s) and inform the allocation result to the SDN agent  202  to create a corresponding set of messages. 
         [0031]    The Resource Manager  203  manages two databases, the one is the Capability List  204  which is shown in  FIG. 3  and another is the Serving Resource List  205  which is shown in  FIG. 4  respectively. 
         [0032]      FIG. 3  is a Capability List  300  of CO  201  and CPE  210  both in  FIG. 2  which shows available traffic control feature set in each device. The Capability List consists of columns: Resource ID (Res. ID)  301 , features of CPE  310 , which is broken into each functions  311 , and features of CO  320 , which is broken into each functions  321 . The feature set  311 ,  321  can be a greatest set of possible available at CPE and CO devices. The listed feature names  311 ,  321  in  FIG. 3  are defined in IEEE 1904.1™ Standard for Service Interoperability in Ethernet Passive Optical Networks (SIEPON) specification published from The Institute of Electrical and Electronics Engineers, Inc. (IEEE) as an example but it can be defined uniquely by a system depend on its supported feature and operator&#39;s requirement. SIEPON specification defines functional blocks as following (defined in section 6.2.1.1 of the specification); 
         [0033]    Input block; 
         [0034]    Classifier block; 
         [0035]    Modifier block; 
         [0036]    Policer/Shaper block; 
         [0037]    CrossConnect block; 
         [0038]    Queues block; 
         [0039]    Scheduler block; and 
         [0040]    Output block. 
         [0041]    For the traffic forwarding perspective, Classifier, Modifier, Policer/Shaper, Queue, and Scheduler contribute major roles in the above listed, and then utilize them as the function set to be managed in the Capability List in  FIG. 3 . 
         [0042]    A column Res. ID  301  in the table in  FIG. 3  shows a combination of resources of CO  201  and CPE  210  in  FIG. 2 ; the Virtual Access Node  220  has a multi-branch topology among CO  201  and CPE  210 . Res. Id. 1-1 stands a combination of CPE #1 is connecting to the interface #1 of the CO, J-N stands a combination of CPE #N is connecting to the interface #J of CO as well. Cross point of each matrix shows a support status of the function in the corresponding device. If marked as “Supported”, the function is supported and functional by the device while marked as “Not Supported”, the function is neither exist, available, nor enabled. 
         [0043]    The Capability List  300  also provides number of resources as a part of capability information. After each remark of Supported, there is a suffix numbering that is presenting existing resources to be used. “Supported 1 (an example is the cross point of Res. ID 1-1 and CPE Classifier)” means the function has one resource and “Supported 10 (an example is the cross point of Res. ID 1-1 and CO Classifier)” means the function has ten resources. The information will be used when determining a new service flow can be admitted to establish or not. 
         [0044]    Note that the Capability List  300  should not be limited to the shown function set in the  FIG. 3 , however it can be varied and extensible or reduced by access technology in use. 
         [0045]    The Resource Manager  203  in  FIG. 2  identifies which device, either CPE and/or CO, has capabilities to complete the request from SDN management system  230 . Analogy of the determination of the resource(s) to serve for the requested function is a system matter, and then the selection algorithm is outside from this patent. 
         [0046]    Once the Resource Manager  203  made a decision for the resource to serve the request, the Resource Manager  203  updates the Serving Resource List  400  which is shown in  FIG. 4 . The Serving Resource List  400  shows which capabilities are used for flow basis. Since the SDN Management System  230  has no visibility of which resources are actually used inside of the CO  201 , the CPE  210 , nor Virtual Access Node  220 , the virtual Access Node  220  needs to maintain the resource usage by its own. 
         [0047]    There are two example flows in the Serving Resource List  400  in the  FIG. 4 . They are Flow ID 1 and Flow ID 2 as shown in Flow ID  402 . Listed functions  411 ,  421  for CPE  410  and CO  420  respectively in the Serving Resource List  400  are corresponding with those in the Capability List  300 . In the Serving Resource List  400 , each function is noted either “Use”, “No use” for available flows where the function exists. When specific feature is not supported in the Capability List  300 , the usage status must be “NA (Not Available)” in the Serving Resource List  400 . Therefore, the Resource Manager  203  can identify that classifier and modifier in the CPE #1 have been used and Policer/shaper and scheduler in the interface #1 of the CO have been used. 
         [0048]    With understanding number of existing resources of each function in the Capability List  300 , it is possible to know whether there is an available resource to be used for new Flow request. Here is an example; Res. ID 1-1 has one CPE Classifier as the resource of CPE #1, and the resource has been used for Flow #1 from the Serving Resource List  400 . Then, there is no more resource to be served for new Flow within CPE #1 if requested. Therefore when the SDN Management System  230  request the Virtual Access Node  220  to create a new Flow #X passing through CPE #1 which requires the Classifier in the CPE #1, the request will be rejected. The same mechanism and judgment is true for the CO case. And the Flow establishment will be examined by checking full set of the required feature set is whether exists and available. 
         [0049]    The Resource Manager  203  informs to the SDN Agent  201  for which resources are capable and available to complete the requested action from the SDN management system  230  when the Resource Manager determines the request is accepted. 
         [0050]    By receiving the resource information from the Resource Manager  203 , the SDN Agent  201  generates a set of messages to control each resource independently both in the CO  201  and the CPE  210 . The SDN Agent  201  forwards the control messages to the Protocol Translator  206  which translates a SDN control message set to a legacy control message set which is used by the access network system  220 . The SDN Agent has a knowledge base which maintains a relationship between SDN control message used with SDN Management System  230  and legacy control message used to control CO  201  and CPE  210  resources internally in the access network system  220 . The relation does not have to be one to one but it can be one to many or many to one, the translation rule will be varied by the access network system and the translation rule itself is out of the scope from this patent. When CO and CPE are SDN native devices however their message set has a different arrangement with the SDN message used by SDN manager  230 , the knowledge base can be expand to maintain the translation and mapping between those two sets of SDN control message. 
         [0051]    The Protocol Translator  206  determines a Destination Address (DA) to each control message. Examples of the DA are IP address, MAC address, Logical Link Id, device Id which is identical to find a corresponding CO and/or CPE. Then assembled control messages are forwarded to the Message Parser  207 . 
         [0052]    The Message Parser  207  identifies address information in the message header which is usually defined as Destination Address (DA) and forwards each legacy control message to the resource in the CO  201  or forwards it to the CPE  210  through the control channel  209 . When CPE  210  receives the legacy control message through the control channel  209 , the Message Parser  212  in the CPE  210  redirects the control message to the Processor  211  in the CPE  210  to interpret the request. The Processor  211  configures own flow forwarding resource  213  and replies an acknowledgement if it&#39;s the protocol. 
         [0053]      FIG. 5  shows a use case that SDN CPE  510  supports native SDN control message processing capability in the SDN module  511  which is attached on top of the CPE  510  which is relevant to the CPE discussed as the CPE  210  in the  FIG. 2 . This use case is discussed in industry groups such that European Telecommunications Standards Institute (ETSI) and Broadband Forum (BBF). ETSI GS NFV 001 V1.1.1 (2013-10) is publicly available and it is discussing the SDN native CPE in the “Use Case #9: Fixed Access Network Functions Virtualisation” in the Section 13. With regards to the proposed configuration of the paper, this patent can adapt in following two manners.
       (a) The first case is to handle CO  501  and CPE  510  as standalone SDN native devices. The Resource Manager  203  in the  FIG. 2  has no role to allocate resource(s) to complete the request from the SDN Management System  530 ; it means that the SDN Management System  530  knows an exact SDN control message(s) to configure each device. By receiving the SDN control message from the SDN Management System  530  at CO  501 , the Resource Manager  203  will simply update the usage status in the Serving Resource List  205  based on the request.   (b) The second case is an access network is virtualized as a single SDN node  520  and SDN Management System  530  only identifies the node but not each CO  501  nor CPE  510 . In this case it is assumed that the SDN control message is targeted to control an abstracted function but not control the exact application interface of each device. The SDN Agent  202  in the  FIG. 2  understands the SDN controller sends a SDN message to configure the Virtual Access Node  520 , and then request the Resource Manager  203  to allocate a resource(s). After the resource allocation, as same as the case to control legacy system, the SDN Agent  202  generates a set of SDN control messages to control each CO  501  and CPE  510  individually. Once the set of SDN messages for each device is generated, there is no need to translate the SDN control message to a legacy control message. And then, the SDN Agent forwards the control messages to the message parser  207  directly, and it then forwards the messages to the each of flow forwarding resource.       
 
         [0056]    SDN control message such as OpenFlow is defined as a protocol being used in the layer three (3); i.e., network layer. In both cases discussed in [0035], at the time of forwarding a SDN control message to a CPE via a CO, there is a possibility that the SDN control message needs to be forwarded in the layer two (2); i.e., datalink layer, but not in the layer three (3). Since the SDN control message is defined as the layer three message, forward it in the layer two requests the layer three message to be encapsulated in the layer two message. Patent filed as Ser. No. 14/256,011 entitled “ARCHITECTURE FOR AN ACCESS NETWORK SYSTEM MANAGEMENT PROTOCOL CONTROL UNDER HETEROGENEOUS NETWORK MANAGEMENT ENVIRONMENT” invented by Toshihiko Kusano has already proposed a solution for the encapsulation. 
         [0057]      FIG. 6  shows a use case with mixed configuration both of SDN non-native CPE  610  and SDN native CPE  611  in the Virtual Access Node  620 , they exist simultaneously under the same CO  601 . In this use case, both CPEs can be managed seamlessly from the SDN Management System  630  with utilizing the mechanism discussed in this patent.