Internet DRAFT - draft-lin-cdni-mobile-caching-framework

draft-lin-cdni-mobile-caching-framework











       CDNI Working Group                                     T. Lin                 
       Internet Draft                                          Y. Li 
       Intended status: Informational                       Y. Zhang                 
       Expires: February 2016                                 S. Ren                 
                                                            IIE, CAS 
                                                     August 17, 2015 

                                          
          A collaborative framework for in-network caching in mobile 
                                  networks 
                  draft-lin-cdni-mobile-caching-framework-00 


       Status of this Memo 

          This Internet-Draft is submitted in full conformance with the 
          provisions of BCP 78 and BCP 79. 

          Internet-Drafts are working documents of the Internet 
          Engineering Task Force (IETF), its areas, and its working 
          groups.  Note that other groups may also distribute working 
          documents as Internet-Drafts. 

          Internet-Drafts are draft documents valid for a maximum of 
          six months and may be updated, replaced, or obsoleted by 
          other documents at any time.  It is inappropriate to use 
          Internet-Drafts as reference material or to cite them other 
          than as "work in progress." 

          The list of current Internet-Drafts can be accessed at 
          http://www.ietf.org/ietf/1id-abstracts.txt 

          The list of Internet-Draft Shadow Directories can be accessed 
          at http://www.ietf.org/shadow.html 

          This Internet-Draft will expire on February 17, 2016.
          
       Copyright Notice 

          Copyright (c) 2015 IETF Trust and the persons identified as 
          the document authors. All rights reserved. 

          This document is subject to BCP 78 and the IETF Trust's Legal 
          Provisions Relating to IETF Documents 
          (http://trustee.ietf.org/license-info) in effect on the date 
          of publication of this document. Please review these 
          documents carefully, as they describe your rights and 
          restrictions with respect to this document. Code Components 
          extracted from this document must include Simplified BSD 
          License text as described in Section 4.e of the Trust Legal 
        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 1] 
        
















       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          Provisions and are provided without warranty as described in 
          the Simplified BSD License. 

       Abstract 

          This document presents a framework for in-network caching in 
          LTE mobile networks. The purpose of the framework is to 
          provide an overall picture of the problem space of in-network 
          caching and to describe the relationships among the various 
          components of mobile networks and the newly added entities, 
          such as content nodes and content controller. The framework
          requires the specification of interfaces and mechanisms to 
          address issues such as content placement, request routing 
          and content catalog maintenance. The intent of this document
          is to outline what each interface needs to accomplish and to
          describe how these interfaces and mechanisms fit together,
          while leaving their detailed specification to other documents.  

       Table of Contents 

           
          1. Introduction and Scope .................................2 
             1.1. Terminology........................................3 
          2. Framework overview .....................................3 
          3. Content retrieval operation flow .......................7 
          4. Interface introduction ................................10 
          5. Example of collaborative caching ......................12 
             5.1. Distributed caching decision example..............12 
             5.2. Centralized caching decision example..............13 
             5.3. Collaborative caching decision example............13 
          6. References ............................................15 
           
       1. Introduction and Scope 

          The explosive growth of mobile video traffic brings a great 
          pressure on LTE mobile networks. Rencent researches have shown 
          deploying caches in 3G/LTE mobile networks can efficiently 
          relieve this pressure by reducing duplicate content 
          transmissions [1-3]. This document provides a collaborative
          caching framework for LTE mobile networks with caches 
          deployed at the evolved packet core (EPC) and radio access
          network (RAN) to reduce the bandwidth cost of Internet 
          access and improve the end-user experience in terms of delay
          and congestion. Specifically, this document describes the 
        
		
       T. Lin et al.,      Expires February 17, 2016        [Page 2] 
           

















       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          necessary content retrieval operation flows and interfaces 
          in general terms and outlines how they fit together to 
          form a complete system for collaborative in-network caching. 
          This document makes use of three examples to illustrate the
          operation of various caching schemes, but these examples 
          should be considered illustrative rather than prescriptive. 

          It is worthy to be noted that deploying transparent caches in 
          LTE mobile networks needs carefully design to adapt to the 
          LTE protocols and specifications, in order not to affect the 
          normal operation of mobile networks. Besides, once caches 
          are deployed at mobile base stations, some important issues, 
          such as mobility and billing, may become main concerns and 
          needs to be well addressed. The above mentioned problems are 
          out of the scope of this document and we leave the solution 
          of these problems to other documents. 

       1.1. Terminology 

          Edge content node: a storage node located at the eNodeB that 
          caches the content according to the predefined caching 
          mechanism. It can be embedded in the eNodeB or cascades to 
          the eNodeB. 

          Central content node: a storage node located at the Core 
          network in the LTE (PDN-GW or SAE-GW) that caches the content 
          according to the predefined caching mechanism. It can be 
          embedded in the PDN-GW(or SAE-GW) or cascades to the PDN-
          GW(or SAE-GW). 

          Content controller: a node in the LTE that connects the 
          content nodes logically in order to collect the information 
          from the content nodes and generate caching policy. It is 
          usually located in LTE core network. 

       2. Framework overview 

          Deploying content caching capability in mobile network 
          provides a brilliant solution in alleviating the pressure of 
          mobile traffic growth and improving user experience. However, 
          caching management faces a huge challenge because of the 
          large number of content nodes and the limitations of storage 
          capacity, especially when considering the limited user number 
        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 3] 
           

















       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          for each edge content node. In this case, collaborative 
          caching is an effective method to improve the overall 
          efficiency of mobile caching networks. 

          This document provides a framework of collaborative caching 
          in mobile networks, as illustrated in Figure 1. In addition 
          to the existing network entities, such as Base Station and 
          Mobile gateway, two kinds of logical entities, namely, 
          content node and content controller, are defined in this 
          figure.  

          Content node is an entity with the capability of computation 
          and storage to support transparent content caching. According 
          to the deployment location, content node can be further 
          classified into edge content node and central content node. 
          Edge node is collocated with base station (i.e., eNodeB), 
          while central content node is collocated with mobile gateway, 
          such as the serving gateway (SGW) and the packet data gateway 
          (PGW). Note that content node can be a physical entity 
          cascade to base station or mobile gateway, as shown in figure 
          1, or it can be embedded with base station or mobile gateway. 

          Content controller is a control plane node, communicateing 
          with all the content nodes. It periodically collects 
          information from each content node. The collected information 
          should include, but is not limited to, content items, user 
          request records, and available uplink bandwidth. The above 
          mentioned information can be collected through the outband 
          interface between content nodes and the controller, i.e., the 
          IP/MPLS interface implemented in the commercial mobile 
          caching system [4]. 

          Based on the collected information, the macro-scale global 
          knowledge of content popularity distribution can be inferred 
          by the content controller. With the global popularity 
          distribution, the content controller can, but not necessarily 
          must, periodically run the content placement algorithm to 
          decide in which content node a content item should be stored. 
          Meanwhile, since the content controller also keeps track of 
          the available serving capacity as well as the content catalog 
          at each content node, it can execute the request routing as a 
          content catalog server to decide which content node a 
          content request should be forwarded to.  


        
       T. Lin et al.,      Expires February 17, 2016        [Page 4] 
           





       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          According to different caching policy, the decision of 
          content placement can be divided into three manners, namely, 
          distributed, centralized and cooperative, which will be 
          detailed in Section 5. In the case of distributed caching 
          policy, content placement is decided locally by content nodes 
          themselves. However, with centralized and cooperative caching 
          policy, content controller enforces the decision of content 
          placement.  

          Due to the centralized feature of this collaborative caching 
          scheme, the issue of scalability should be of concern.  To 
          this end, the content controller, as a logical entity, can be 
          easily scaled by being deployed on a cloud platform. 































        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 5] 
           






       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 

         
                ------------------------------------------------            
               /       +--- +      +--- +       +--- +           \          
              /        |CP1 |      |CP2 |       |CP3 |            \         
              \        +--- +      +--- +       +--- +            /         
               \                 INTERNET                        /          
                ------------------------------------------------            
          -------------------------- ||------------------------------       
                                     ||                                     
                                  --------                                  
                                 / Central \                                
              |================= | Content |========================|       
              ||                 \  Node   / *************         ||       
              ||               // ----*---               *         ||       
              ||              //      *                  *         ||       
              ||             // +-----*--- +         ----*------   ||       
              ||            ||  |  Mobile  |        / Content    \ ||       
              ||            ||  |  Gateway |        | Controller | ||       
              ||            ||  +-----*--- +        \            / ||       
              ||            ||        *              -----------   ||       
              ||  *********************************************    ||       
              ||  *         ||        *                        *   ||       
              ||  *         ||        *                        *   ||       
             -||--*--       ||    ----*---                  ---*---||       
            /  Edge   \     ||   /  Edge   \               /  Edge   \      
            | Content |     \====| Content |    ......     | Content |      
            \  Node   /          \  Node   /               \  Node   /      
             ---*----             ---*----                  ---*----        
                *                    *                         *            
                *                    *                         *            
            +---*----- +        +----*---- +             +-----*--- +       
            |   Base   |        |   Base   |             |   Base   |       
            | Station  |        | Station  |   ......    | Station  |       
            +--------- +        +--------- +             +--------- +       
                                     *                                       
           ------------------------- *----------------------------
                                     *                                     
                 +--------+        +--------+        +--------+             
                 |Terminal|        |Terminal|        |Terminal|             
                 +--------+        +--------+        +--------+       

                 *****  LTE link                                            
                 =====  Outband link
         
          Figure 1 Logical framework of collaborative caching in mobile 
                                    networks 
									
       T. Lin et al.,      Expires February 17, 2016        [Page 6] 
           





       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
 

       3. Content retrieval operation flow 

       3.1. Case 1: the content controller and the central content node 
          are not co-located in the same entity. 

          As illustrated in Figure 2, the content retrieval operation 
          flow is based on the following steps: 

          When receiving a content request from a mobile client, edge 
          content node A checks whether the requested content exists in 
          its local cache (step 1 in Figure 2). If hit, edge content 
          node A delivers the content directly to the client (step 7); 
          Otherwise, edge content node A inquires the content 
          controller for the missing request (step 2). 

          If the requested content is found in the caching system 
          within the mobile network, the content controller returns an 
          802 redirect message in which the IP address of target 
          content node is included (step 3). Then edge content node A 
          retrieves the requested content from target content node B 
          (step 4.1 and 4.2). 

          If the content is not found in the caching system, the 
          content controller also returns an 802 redirect message in 
          which the IP address of the central content node is included 
          (step 3). Subsequently, edge content node deliver a http 
          request message to the central content node (step 5.1) and 
          finally the requested content is retrieved from the original 
          server which is located somewhere outside the mobile network 
          (step 6.1,6.2 and 5.2). 


          Once edge content node A has retrieved the requested content,
          it delivers the content to the client (step 7).


	  
	  
	  
	  
	  
	  
	  

        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 7] 
           






       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

            Client     Edge        Content   Target   Central   Original 
                     Content     Controller Content   Content     Server 
                      Node A                 Node B    Node    
            |           |            |        |         |             |  
            |1.http req.|            |        |         |             | 
            |---------->|            |        |         |             | 
            |           |2.http req. |        |         |             | 
            |           |----------> |        |         |             | 
            |           |3.http 802  |        |         |             | 
            |           |<-----------|        |         |             | 
            |           |            |        |         |             | 
           -|           |4.1 http req.        |         |             | 
          / |           |-------------------->|         |             | 
       Found|           |4.2 http rep.        |         |             | 
          \ |           |<--------------------|         |             |  
           -|           |            |        |         |             |  
            |           |5.1 http req.        |         |             |  
           -|           |------------------------------>|             |  
          | |           |            |        |         |6.1 http req.|  
       Not  |           |            |        |         |------------>|  
       found|           |            |        |         |6.2 http rep.|  
          | |           |            |        |         |<------------|  
          \ |           |5.2 http rep.        |         |             |  
           -|           |<------------------------------|             |  
            |7.http rep.|            |        |         |             | 
            |<----------|            |        |         |             | 
            |           |            |        |         |             |  
           
                   Figure 2 Content retrieval flow for case 1 

       3.2. Case 2: the content controller and the central content node 
          are co-located in the same entity. 

          As illustrated in Figure 3, the content retrieval operation 
          flow is based on the following steps: 

          When receiving a content request from a mobile client, edge 
          content node A checks whether the requested content exists in 
          its local cache (step 1 in Figure 3). If hit, edge content 
          node A delivers the content directly to the client (step 6); 
          Otherwise, edge content node A inquires the content 
          controller for the missing request (step 2). 


        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 8] 
           





       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          If the requested content is found in the central content node 
          which is co-located with the content controller, the content 
          controller directly satisfies the request through returning a 
          http reply message (step 3.2). 

          If the requested content is found in other edge content nodes, 
          the content controller returns an 802 redirect message in 
          which the IP address of target content node is included (step 
          3.1). Then edge content node A retrieves the requested 
          content from target content node B (step 4.1 and 4.2). 

          If the content is not found in the caching system, the 
          content controller delivers an http request message to the 
          original server which is located somewhere outside the mobile 
          network (step 5.1) and finally retrieves the requested 
          content from the original server(5.2 and 3.2). 


























		  

        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 9] 
           






       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          Client    Edge     Content Controller      Target     Original 
                    Content    /Central Content      Content      Server 
                    Node A           Node            Node B      
              |           |              |                |          |  
              |1.http req.|              |                |          |  
              |---------->|              |                |          |  
              |           |2.http req.   |                |          |  
              |           |------------->|                |          |  
              |           |              |                |          |  
             -|           |3.1http 802   |                |          |  
       Found/ |           |<-------------|                |          |  
       but    |           |4.1http req.                   |          |  
       not    |           |------------------------------>|          |  
       central|           |4.2http rep.                   |          |  
       node \ |           |<------------------------------|          |  
             -|           |              |                |          |  
             -|           |              |5.1http req.    |          |  
            / |           |              |-------------------------->|  
       Not |  |           |              |5.2http rep.    |          |  
       found  |           |              |<--------------------------|  
            \ |           |3.2http rep.  |                |          |  
             -|           |<-------------|                |          |  
              |6.http rep.|              |                |          |  
              |<----------|              |                |          |  
              |           |              |                |          |  
			  
                   Figure 3 Content retrieval flow for case 2 

       4. Interface definition 

          Figure 4 illustrates the logical connections and interfaces 
          between content nodes and the content controller. The 
          outlined specifications of the interface functions are listed 
          in the following parts.  






		  
		  
		  


        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 10] 
           






       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          +-----------------------------------------------------+ 
          |                                                     | 
          |  ---------------                 + ---------- +     | 
          | /     Central   \                |  Content   |     | 
          | |    Content     * * * * * * * * * Controller |     | 
          | \      Node     /                + -*--*---*- +     | 
          |  ---------------                    *  *   *        | 
          |     * * * * * * * * * * * * * * * * *  *   *        | 
          |     *                                  *   *        | 
          |     *              * * * * * * * * * * *   *        | 
          |     *              *                       *        | 
          |     *              *                       *        | 
          |  ---*-----      ---*-----             -----*---     | 
          | /  Edge   \    /  Edge   \           /  Edge   \    | 
          | | Content |    | Content |  ......   | Content |    | 
          | \  Node   /    \  Node   /           \  Node   /    | 
          |  ---------      ---------             ---------     | 
          |                                                     | 
          |                                                     | 
          |                                                     | 
          |              ***** INTERFACE                        | 
          |                                                     | 
          |                                                     | 
          |                                                     | 
          +-----------------------------------------------------+ 
           
                             Figure 4 Control plane 

          The interface between content nodes and content controller 
          can be categorized in two kinds: node management interface
          and content management interface. The specific functions of
          the interface are as below: 

          Node management interface, including: 

            a) Node join notification. Whenever a content node joins 
               the system, the controller is notified via the interface.
            b) Node quit notification. Whenever a content node quits 
               from the system, the controller is notified via the 
               interface. 
            c) Node status report. Node status includes link load 
               condition, uplink bandwidth, download bandwidth, etc. 
        
        
       T. Lin et al.,      Expires February 17,2016        [Page 11] 
           






       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

               Each content node periodically reports the above status 
               information to the content controller via the interface.
               The message of node status report can also be used for 
               the purpose of keep alive between content node and 
               content controller.   
          Content management interface, including: 

            a) Caching information report. The caching information, 
               such as local cache size, cached content items, and 
               average hit ratio, can be reported to the content 
               controller via the interface. 
            b) Http request/reply. When a request cannot be satisfied 
               at an edge content node, an Http request routing 
               procedure is performed between the edge content node and 
               content controller via the interface, as illustrated in 
               Figure 2 and Figure 3. 
            c) Content placement strategy notification. When a new 
               content placement strategy is generated or updated, the 
               content controller notifies the strategy to content 
               nodes via the interface. 
            d) Content retrieval record report. Content nodes 
               periodically report its content retrieval record to the 
               content controller. Based on the collecting content 
               retrieval record from each edge content node, the 
               content controller can have the knowledge of a global 
               content popularity which may be used to generate or 
               update the next round content placement strategy. 
           

       5. Example of collaborative caching 

          The collaborative framework for in-network caching in mobile 
          edge networks could support different kinds of caching 
          policies. Here three typical caching decision examples are 
          provided. 

       5.1. Distributed caching decision example 

          In this case, each cache makes its own caching decision 
          independently. Every cache determines the content popularity 
        
        
		
		
		
       T. Lin et al.,      Expires February 17, 2016        [Page 12] 
           









       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          according to its local historic content request statistic 
          information, and then caches the most popular contents in its 
          storage periodically. Meanwhile, the cache node reports its 
          cached contents to the controller, in order to generate the 
          whole content catalog. 

          The contents being cached should be got actively through 
          sending the request by the edge content node, or should be 
          intercepted passively during the contents passed by. 

          Such distributed caching decision mechanism could cause the 
          caching redundancy since each edge content node cache the 
          similar popular contents, leading to the lower cache 
          utilization. 

       5.2. Centralized caching decision example 

          In this case, the content controller, instead of the content 
          nodes, makes the caching decision centrally. The content 
          controller collects the content requests periodically to get 
          the content popularity, and informs each edge content node 
          what to cache. Thus, all the edge content nodes can cache the 
          popular contents heterogeneously in a complementary way. 
          Furthermore, the content controller keeps a catalog to record 
          the storage location of the cached content, in order to 
          redirect the request from one edge content node to the other 
          edge content node(s). 

          When received the caching decision from the content 
          controller, the edge content node should actively get the 
          content through sending the request, or should passively 
          intercept during the contents passed by. 

          Such centralized caching decision mechanism could cache the 
          maximum contents in the RAN, therefore reduce the egress 
          traffic and increase cache utilization, at a cost of an extra 
          controlling overhead and longer download delay. 

       5.3. Collaborative caching decision example 

          In this case, the cache size of the edge content node is 
          divided into two independent parts, the non-coordinated local 
          cache part and the coordinated shared cache part, as shown in 
          Fig. 5. To simplify the analysis and without loss of 
        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 13] 
           





       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          generality, we assume that there are n edge content nodes 
          which has the equal cache size c and the equal upstream link 
          capacity. Each edge content node stores in its local cache 
          (i.e., the c-x portion) the top ranked contents in a non-
          coordinated manner, and all edge content nodes 
          collaboratively store n.x contents that are ranked from c-x+1 
          to c-x+nx. In order to manage the coordinated caching across 
          the RAN, the content controller has to collect the 
          information of content popularity and disseminate contents to 
          the corresponding edge content nodes periodically. Hence, the 
          content controller keeps the catalog recording the cached 
          content location, in order to redirect the request from one 
          edge content node to the other edge content node(s). 

                                 --------------                        
                                /    Central    \                       
                                |    Content    |                       
                                \     Node      /                       
                                 -*---*--*--*--                       
                                  *   *  *  *                           
                    * * * * * * * *   *  *  *                         
                    *                 *  *  * * * * * * * * *         
                    *                 *  *                  *           
                    *                 *  *                  *           
                    *             * * *  * * * *            *           
                    *             *            *            *           
                    *             *            *            *           
                    *             *            *            *           
                    *             *            *            *         
                 ---*-----     ---*-----     ---------     -*-------    
                /  Edge   \   /  Edge   \   /  Edge   \   /  Edge   \    
                | Content |   | Content |   | Content |   | Content |    
                \  Node 1 /   \  Node 2 /   \  Node 3 /   \  Node 4 /    
                 ---------     ---------     ---------     ---------    
                                                            
              + ------- + ---- +                            
              |   c-x   |  x   |                            
              + ------- + ---- +                            
                local    shared                             
                cache    cache                              
           
                 Figure 5 Collaborative caching decision example 


        
       T. Lin et al.,      Expires February 17, 2016        [Page 14] 
           





       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

          Such collaborative caching decision mechanism could increase 
          cache utilization, and reduce download delay at the same time, 
          at a cost of communication and controlling overhead. 

           

       6. References
          [1] J. Erman, A. Gerber, M.T. Hajiaghayi, D. Pei, S.Sen,
               O.Spatscheck, To Cache or Not to Cache - The 3G Case. 
               IEEE Internet Computing, vol. 15, no. 2, Mar. 2011, 
               pp. 27-34.
          [2] S. Woo, E. Jeong, S. Park, J. Lee, S. Ihm, and K. Park,
               "Comparison of caching strategies in modern cellular 
               backhaul networks," inACM11th annual international 
               conference on Mobile systems, applications,and services,
               2013, pp. 319-332.
          [3] B. A. Ramanan, L. M. Drabeck, M. Haner, N. Nithi, 
               T. E. Klein, and C. Sawkar, "Cacheability analysis of
               HTTP traffic in an operational LTEnetwork," in IEEE 
               Wireless Telecommunications Symposium (WTS),2013, 
               pp. 1-8.
          [4]  Saguna, "Saguna networks enables mobile network 
                operators to mon-etize their radio networks,"
                http://www.saguna.net/site/assets/files/1/intel_saguna 
                networks_whitepaper.pdf/ 





















       T. Lin et al.,      Expires February 17, 2016        [Page 15] 
           






       Internet-Draft                     
       A collaborative framework for in-network caching in mobile 
       networks                           
       August 2015 
           

       Authors' Addresses 

          Tao Lin 
          Institute of Information Engineering 
          Chinese Academy of Sciences 
          No.89, Minzhuang Road, Haidian District, Beijing 100093 
          P.R. China 
             
          Email: lintao@iie.ac.cn 
           

          Yang Li 
          Institute of Information Engineering 
          Chinese Academy of Sciences 
          No.89, Minzhuang Road, Haidian District, Beijing 100093 
          P.R. China 
             
          Email: liyang@iie.ac.cn 
           

          Yan Zhang 
          Institute of Information Engineering 
          Chinese Academy of Sciences 
          No.89, Minzhuang Road, Haidian District, Beijing 100093 
          P.R. China 
             
          Email: zhangyan@iie.ac.cn 
           

          Shoushou Ren 
          Institute of Information Engineering  
          Chinese Academy of Sciences 
          No.89, Minzhuang Road, Haidian District, Beijing 100093 
          P.R. China 
             
          Email: renshoushou@iie.ac.cn 
           






        
        
       T. Lin et al.,      Expires February 17, 2016        [Page 16]