MIF Hongke Zhang Internet Draft Fei Song Intended status: Informational Boxin Du Expires: November 18 2018 Mi Zhang Beijing Jiaotong University May 17, 2017 MIF API extension for combining IEEE 802.2 draft-zhang-mif-api-extension-802-21-06.txt Abstract The Application Program Interface (API) of MIF, specified in the MIFAPI consideration, must rely on lower layer functionalities when handover between homogeneous or heterogeneous networks is necessary. To improve the connectivity performance, the existing MIF API needs to be extended. IEEE is also aimed at the similar issue from different way. A kind of logical entities over the link layer protocol for handling the seamless handover has been defined in IEEE802.21. This document proposes a mechanism via integrating MIF API and IEEE 802.21 to support application service better. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/ current/. 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." This Internet-Draft will expire on November 18, 2018. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires November 17,2018 [Page 1] Internet-Draft MIF API extension May 2017 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 Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 2. Terminology .................................................. 3 3. The Relationship between IEEE MIHF and MIF API ............... 3 4. The Extension of MIF API for Handover: A Case Study........... 7 4.1. The MN-initiated Handover ............................... 7 4.1.1. Get Information .................................... 7 4.1.2. Information Post ................................... 8 4.1.3. Parameter Report ................................... 8 4.1.4. Check Resources MN ................................. 8 4.1.5. Resource Availability .............................. 8 4.1.6. Connect to Interface ............................... 8 4.1.7. Resource Preparation Messages ...................... 9 4.1.8. Establish Link Messages ............................ 9 4.1.9. Link Up ............................................ 9 4.1.10. Handover Completed ................................ 9 4.1.11. Handover Completion Confirmation .................. 9 4.2. The Network-initiated Handover .......................... 9 4.2.1. Candidate Query Notification ...................... 10 4.2.2. Candidate Query Result ............................ 10 4.2.3. Check Resources Net ............................... 10 4.2.4. Confirm Chosen Target ............................. 11 4.2.5. Establish Link Messages ........................... 11 4.2.6. Link Up ........................................... 11 4.2.7. Handover Completed ................................ 11 4.2.8. Handover Completion Confirmation .................. 11 5. Discussions for New Messages from MIF Perspective ........... 11 5.1. Get Information......................................... 11 5.2. Release the Ongoing Connection ......................... 12 5.3. Establish New L2 Connection ............................ 12 6. Discussions for New Messages from IEEE Perspective............12 7. Security Considerations ..................................... 15 8. IANA Considerations ......................................... 15 9. References .................................................. 15 9.1. Normative References ................................... 15 9.2. Informative References ................................. 15 Zhang, et al. Expires November 17,2018 [Page 2] Internet-Draft MIF API extension May 2017 10. Acknowledgments ........................................... 15 1. Introduction In MIF context, improved connectivity experiences SHOULD be created. The main target is to enhance the performance of horizontal and vertical switches between networks. Such situation is quite similar with Media Independent Handover (MIH) described in [IEEE 802.21]. The MIF Application Program Interface (API) specified in the MIF API consideration [I-D.ietf-mif-api-extension] describes a set of message calls to accomplish higher level APIs which solve the problems in multiple interface scenarios. However, this draft only provides a minimal set of message calls REQUIRED to implement the API. New functions could be added. According to [IEEE 802.21], the Media Independent Handover Function (MIHF) is a logical entity that facilitates MIH decision making based on inputs from the MIHF. It can provide abstracted services for higher layers. Communications with the lower layer of the mobility- management protocol stack can be achieved through technology-specific interfaces in MIHF. Although two mechanisms, MIF API and MIHF, are working in different layers and defined by different organizations, the requirements of compatibility are obvious. Some of the functions of MIF API SHOULD be supported by a connection manager (i.e. the MIHF), and vice versa. Owing to the advantages of both MIHF and its Service Access Points (SAPs), the functions of MIHF could be utilized in MIF API in order to handover issues. This document extends message calls of MIF API to support the MIH. Like [I-D.ietf-mif-api-extension], no bindings for programming languages are provided because they are left up to the implementation. This document only describes the messages sending and receiving, which can be read as a checklist for operating system vendors. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. The Relationship between IEEE MIHF and MIF API Through facilitating handover among all IEEE 802 networks regardless of whether they are of different media types or not, including both wired and wireless, the purpose of IEEE 802.21 is to improve the user experience of mobile devices. It also aims at making it possible for Zhang, et al. Expires November 17,2018 [Page 3] Internet-Draft MIF API extension May 2017 mobile devices to perform seamless handover between IEEE 802 and non IEEE networks. This standard defines: 1. A framework that enables service continuity while a Mobile Node (MN) transitions between heterogeneous link-layer technologies. 2. MIHF. 3. MIH_SAP and associated primitives for users to get services of MIHF. 4. The definitions of new link-layer SAPs and associated primitives for each link-layer technology. They help MIHF to collect link information and control link behaviors during handovers. The content of MIHF is a functional entity to fulfill the high- performance handovers. The primary advantage of MIHF is that it provides media-independent services to higher layers no matter which media-specific technology of lower layer is being used, such as IEEE Std.802.3, IEEE Std.802.11, IEEE Std.802.16, 3GPP and 3GPP2. It also defines three kinds of SAPs (will be detailed later) of MIHF and their primitives that interact between different layers. The MIHF can also act as a filter: the messages received from link layer SHOULD be processed and submitted to higher layer for meeting the subscribers' need. Therefore, MIHF should work under MIF API. In fact, MIF API SHOULD be served as a user of MIHF, as shown in Figure 1. The subscribers can then only interact with the MIHF via one kind of SAPs (i.e. MIH_SAP) without knowing the lower things. The MIH protocol is not in the scope of this document. Three kinds of MIHF services are defined in the standard: Media Independent Event Service (MIES), Media Independent Command Service (MICS) and Media Independent Information Service (MIIS). MIES provides event classification, event filtering and event reporting corresponding to dynamic changes in link characteristics, link status and link quality. It originates from lower layers and can be passed to MIHF or upper layers for the detection of handover requirement. MICS enables MIH users to manage and control link behavior relevant to handover and mobility. It is invoked by users or MIHF and makes effect on MIHF or lower layers. For example, in MN-initiated handover scenario, MICS is adopted for MN switching between different links. MIIS allows MN and network entities to discover information which has influence on the selection of appropriate networks during handovers. Figure 2 [IEEE 802.21] shows MIH services and their initiation. Zhang, et al. Expires November 17,2018 [Page 4] Internet-Draft MIF API extension May 2017 +-------------------------------------+ | Application | +-------------------------------------+ /\ || /\ || /\ || || \/ || || || || +--------------+ || || || || |High Level API| || || || || +--------------+ || || || || /\ || || || || || || \/ || \/ || || +------------------------+ || || | MIF API | || || +------------------------+ || || /\ || || \/ || || +--------------------+ || || | Communication API | || || +--------------------+ || || /\ /\ || || || || || \/ \/ \/ +-------------------------------------+ | MIHF | +-------------------------------------+ /\ || || \/ +-------------------------------------+ | Network Link API | +-------------------------------------+ /\ || /\ || || \/ || \/ +---------------+ +---------------+ | Network | | Network | | Interface 1 | | Interface 2 | +---------------+ +---------------+ The relationship of MIHF & MIF API The letters a, b, c in Figure 2 respectively represent: a. MIH_SAP b. MIH_LINK_SAP c. LLC_SAP The SAPs are divided into two categories: 1) Media dependent SAP (including MIH_LINK_SAP and LLC_SAP). Zhang, et al. Expires November 17,2018 [Page 5] Internet-Draft MIF API extension May 2017 2) Media independent SAP (MIH_SAP). +-------------+ Command +-----------------------------+ | + Service | | | / \ <---------------+ | | + + | MIH User | | | | Event | | | MIHF | | Service | Layer 3 or Higher | | | a |--------------->| Mobility Protocol | | Event | | | | | Service | | Information | | | + + Service | | | Command \ /<--------------->| +-------+ +-------+ | | Service + +--+ c +-+---+--+ c +-+ | | Command + +-------+ | + +-------+ | | Information | Service / \ | / \ | | Service |--------------->+ + | + + | | | | | Network1 | | | Network2 | | | Event | | (e.g.IEEE| | | (e.g.IEEE| | | Service | b | 802.16) | | b | 802.11) | | |<---------------| | | | | | | | | | | | | | | | Information | | | | | | | | Service + + | + + | | |<--------------->\ / | \ / | | | + | + | | | | | | | +-------------+ +------------+ +------------+ MIH services and their initiation SAP of the MIHF (i.e. MIH_SAP) is media independent. The MIH_SAP defines the interface between the MIHF and MIH users such as an upper layer mobility protocol or a handover function (e.g., MIF API) that might reside at higher layer transport entity as well. MIH_SAP allows the MIHF to provide services to the upper layers, the network management plane and the data bearer plane. Upper layers need to subscribe with the MIHF as users to receive MIHF events. In MIF case, the MIF API can directly send commands to the local MIHF via messages which use the service primitives of the MIH_SAP. All the messages REQUIRED for communicating successfully in MIF environment that described in the [I-D.ietf-mif-api-extension] MUST also be used here. These messages define the way that MIF API interacts with the higher layers or applications andneed to be added into this set for handover process. These new messages SHOULD be exchanged between MIHF and MIF API. Some of them may use the services of MIHF. Zhang, et al. Expires November 17,2018 [Page 6] Internet-Draft MIF API extension May 2017 4. The Extension of MIF API for Handover: A Case Study This section introduces the extension of message calls of MIF API in two parts based on the classification of handovers (MN-initiated handover and the network-initiated handover). In order to handle these two kinds of handovers successfully, MIF API SHOULD be extended respectively based on the characteristics of process. 4.1. The MN-initiated Handover The handover initated by MN includes the following seven steps: 1) Information query. The MN collects network information from the MIIS server which the MN is connected to. 2) Resource availability check. The MIF API sends request to find candidates and then receives a list of candidate networks in response message. 3) Resource preparation. The MN SHOULD determine which target network is suitable and request it for resource preparation. 4) Establish new L2 connection. The MIF API initiates a new link connection. 5) Link up indication. The MIHF of MN notifies the MIF API that the link is up. 6) Higher layer handover execution. 7) Resource release. The original serving network resources must be released in the end. The following messages need to be added, which describe interactions between a MIHF and MIF APIs. 4.1.1. Get Information This message is sent by the MIF API for the inquiry of the neighboring networks information. In MIH, we can use the MIH_Get_Information. request for the same purpose. After receiving this message, the MIHF inquires the MIIS server for the information, which will return a list of network information for MIF API. Zhang, et al. Expires November 17,2018 [Page 7] Internet-Draft MIF API extension May 2017 4.1.2. Information Post This message is sent to the MIF API by the MIIS server as a response to the Get Information message. MIH_Get_Information. confirm can be used to convey such information. 4.1.3. Parameter Report When attaching to a specific network, the MIF API needs to receive the lower layers link status to better control the whole connection. The MIHF can receive reports from the link layers and submit them to the higher layers. If the link is going down, the MIF API must notify its subscribers using "Interface is going away" message. The application or higher API could try to establish new connections by sending "Wants to connect" to MIHF and the connection process will restart from step 2 (i.e. Resource availability check). Another situation is when the MIF API receives a "Wants to connect" message from its subscriber, the MIF API SHOULD accordingly trigger a whole connection process to a new network accordingly. This can also begin from step 2. 4.1.4. Check Resources MN In the connection starts period, the MN SHOULD check the resource availability at the candidate networks. This message is sent to the MIHF by the MIF API. The serving network SHOULD request each candidate. The final result SHOULD be returned to the higher layer. The MIH_MN_HO_Candidate_Query. request can be used in the MIH case. 4.1.5. Resource Availability When receiving the resource availability of the candidates from the serving network, the MIHF SHOULD submit these messages to the MIF API. The MIH_MN_HO_Candidate_Query confirm can be used in the MIH case. 4.1.6. Connect to Interface This message is sent to the MIF API by the upper applications. When the MIF API receives the Resource Availability, it could post the message to the higher layer. The upper application can use "Connect to Interface" to choose a better network interface. More about the choosing methods need further discussion. Zhang, et al. Expires November 17,2018 [Page 8] Internet-Draft MIF API extension May 2017 4.1.7. Resource Preparation Messages The MIF API can use the MIH_MN_HO_Commit. request, which includes the target network information, to request the network chose for resource preparation. When the preparation is done, the MIHF receives the response from the target network. It sends a MIH_MN_HO_Commit. confirm message to the MIF API in order to inform the status of the previously issued target notification request. 4.1.8. Establish Link Messages MIF API can solve the connection establishment problem using the MIH_Link_Action. request. This message primitively defined by the [IEEE 802.21] is to control the local or remote lower link layers. It includes a MIHF ID and a Link Actions List, which can realize many controlling functions. After the action has been executed, the MIF API should receive a MIH_Link_Action. confirm to indicate the result. 4.1.9. Link Up After the new link is established, the MAC layers MUST deliver a Link_Up. indication to the MIHF. The MIHF then passes the MIH_Link_Up. indication message to the MIF API. The MIF API can notify the upper applications using the "Link is going up" message. Then the higher layer handover execution might be triggered and the traffic flow can be re-established. 4.1.10. Handover Completed This message is sent to the MIF API by the MIHF indicating that the resource of the previous network is successfully released. 4.1.11. Handover Completion Confirmation This message is sent to the MIF API by the MIHF indicating that the resource of the previous network is successfully released. 4.2. The Network-initiated Handover There are also seven steps in an intact network-initiated handover, like the MN-initiated handover: 1) Information query. 2) Resource availability check. 3) Resource preparation. Zhang, et al. Expires November 17,2018 [Page 9] Internet-Draft MIF API extension May 2017 4) Establish a L2 connection using MIH_Link_Action. request. 5) Sent link indications to the MIF API. 6) Higher layer handover execution. 7) Resource release. The differences between Network-initiated case and MN-initiated case are in step 1 and step 2. The Get Information request and Information Query are respectively initiated by the MIH user of the serving network. When such MIH user obtains the information from the MIIS server, it sends requests to the MN for a response message containing the MN's handover acknowledgement, MN's preferred link and PoS lists. In step 3, the commitment of target network is also initiated by the MIH user of a serving network. After the resource is prepared, the PoS of serving network SHOULD notify the MN for the establishment of L2 connection in step 4. The following messages should be added in MIF API. 4.2.1. Candidate Query Notification This message is sent to MN's MIHF from the PoS of the serving network with a list of PoAs of each candidate network link. Such message suggests the MN SHOULD consider new access network. This message can use the MIH_Net_HO_Candidate_Query. indication. 4.2.2. Candidate Query Result This message is sent to the local serving network's MIHF from MN's MIF API, specifying whether the request of handover is permitted or not. MIH_Net_HO_Candidate_Query. response can be used here. When the handover is permitted, a new access network SHOULD be considered at the handover initiation stage. 4.2.3. Check Resources Net This message is sent to the MN's MIF API by the PoS of serving network with a list of target network information and a set of resource parameters assigned to the MN for handover. MIH_Net_HO_Commit indication can be used. Then the MIF API can trigger the establishment of L2 connection by using Link_Action. request. After the link connection is done, MIF API needs to inform Zhang, et al. Expires November 17,2018 [Page 10] Internet-Draft MIF API extension May 2017 the serving network. Link_Action request might also have a list of actions for handover control during the link connection period. 4.2.4. Confirm Chosen Target This message is sent by the MN's MIF API as a response to the MIH_HO_Commit.indication, revealing that the indication is received. MIH_Net_HO_Commit. response can be used. Also such message might include a list of the results of previous actions. 4.2.5. Establish Link Messages This message is exactly the same as that of the MN-initiated process, for establishing a new L2 link connection. 4.2.6. Link Up This message is exactly the same as that of the MN-initiated process, for informing the MIF API that the L2 link is completed. 4.2.7. Handover Completed This message is exactly the same as that of the MN-initiated process, for releasing the resources that have already attained by the MN. 4.2.8. Handover Completion Confirmation This message is exactly the same as that of the MN-initiated process, for confirming that the resources of the previous network are successful. 5. Discussions for New Messages from MIF Perspective New messages described in this document are critical for information exchanging and function achievement between MIHF and MIF API. Since both "upper layer requirements gathering" and "lower layer command delivering" (or reverse) can be achieved via messages, the logical relationship should be discussed in-depth. The messages below are only the examples. Further updating is needed. 5.1. Get Information According to [IEEE 802 21] this information query is related to a specific interface. It has the flexibility to query either a specific data within a network interface or an extended schema of a given network. As an advanced application or upper APIs send "Announce Interface", "Announce PVD" and "Announce IE (Information Elements)", Zhang, et al. Expires November 17,2018 [Page 11] Internet-Draft MIF API extension May 2017 the MIF API could obtain the information via the Get_information. request in MIH. 5.2. Release the Ongoing Connection The [I-D.ietf-mif-api-extension] defines a message "Connection can be broken", which means that the MN can tolerate the connection being broken, e.g. for power conservation. When the subscribers of MIF API delivers this message, the MIF API SHOULD send "Release the ongoing connection" to the MIHF so that directly releasing the current resources of network to cut off this connection. This action will not weaken the application function. 5.3. Establish New L2 Connection According to [IEEE 802.21], the MIH_Link_Actions can trigger a L2 link connection. When MN wants to build a TCP connection with an IP host, the MIF API will receive "Connect to Address" or "Connect to Address from Address" messages. Then the MIF API can use the MIH_Link_Actions. request to ask MIHF for new L2 link connection. 6. Discussions for New Messages from IEEE Perspective The following tables, table1, 2, 3 and 4, are from the [IEEE 802.21]. These messages might be used in the MIF API because they are exchanged between the MIHF and its MIH users. Some of them have been discussed above, but the specific usage of the rest is not represented. This section presents only a direct list of their category and brief descriptions. Further discussion is needed. +---------------------+--------------------------------------------+ | Messages | Description | | (Information) | | +---------------------+--------------------------------------------+ | MIH_Get_Information | Request to get information from repository | +---------------------+--------------------------------------------+ | MIH_Push_Information| Notify the MN of operator policies or | | | other information | +---------------------+--------------------------------------------+ Table 1 Information Messages of MIHF Zhang, et al. Expires November 17,2018 [Page 12] Internet-Draft MIF API extension May 2017 +---------------------+--------------------------------------------+ | Messages (Event) | Description | +---------------------+--------------------------------------------+ | MIH_Link_Detected | Link of a new access network has been | | | detected. This event is typically on the | | | MN when the first PoA of an access network | | | is detected | +---------------------+--------------------------------------------+ | Track_timeout | This event is not generated when | | | subsequent PoAs of the same access network | | | are discovered | +---------------------+--------------------------------------------+ | MIH_Link_Up | L2 connection is established and link is | | | available for use | +---------------------+--------------------------------------------+ | MIH_Link_Down | L2 connection is broken and link is not | | | available for use | +---------------------+--------------------------------------------+ | MIH_Link_Paremeters | Link parameters have crossed a specified | | _Report | threshold and need to be reported | +---------------------+--------------------------------------------+ | MIH_Link_Going_Down | Link conditions are degrading and | | | connection loss is imminent | +---------------------+--------------------------------------------+ | MIH_Link_Handover | L2 handover is imminent based on either | | _Imminent | the changes in the link conditions or | | | additional information available in the | | | network | +---------------------+--------------------------------------------+ | MIH_Link_Handover | L2 handover to a new PoA has been | | _Complete | completed | +---------------------+--------------------------------------------+ | MIH_Link_PDU | Indicate transmission status of a PDU | | _Transmit_Status | | +---------------------+--------------------------------------------+ Table 2 Event Messages of MIHF Zhang, et al. Expires November 17,2018 [Page 13] Internet-Draft MIF API extension May 2017 +--------------------+---------------------------------------------+ | Messages (Command) | Description | +--------------------+---------------------------------------------+ | MIH_Link_Get | Get the status of a link | | _Parameters | | +--------------------+---------------------------------------------+ | MIH_Net_HO | Network initiates handover and sends a list | | _Candidate _Query | of suggested networks and associated points | | | of attachment | +--------------------+---------------------------------------------+ | MIH_Link_Configure | Configure link parameter thresholds | | Thresholds | | +--------------------+---------------------------------------------+ | MIH_Link_Actions | Control the behavior of a set of links | +--------------------+---------------------------------------------+ | MIH_MN_HO_Candidate| Command used by MN to query and obtain | | _Query | handover related information about possible | | | candidate networks | +--------------------+---------------------------------------------+ | MIH_N2N_HO_Query | command sent by the serving MIHF entity to | | _Resources | the target MIHF entity for resource query | +--------------------+---------------------------------------------+ | MIH_MN_HO_Commit | Command used by MN to notify the serving | | | network of the decided target network | | | information | +--------------------+---------------------------------------------+ | MIH_Net_HO_Commit | Command used by the network to notify the | | | MN of the decided target network information| +--------------------+---------------------------------------------+ | MIH_N2N_HO_Commit | Command used by a serving network to inform | | | a target network that an MN is about to | | | move toward that network, initiate context | | | transfer and perform handover preparation | +--------------------+---------------------------------------------+ | MIH_MN_HO_Complete | Notification from MIHF of the MN to the | | | target or source MIHF indicating the | | | status of handover completion | +--------------------+---------------------------------------------+ | MIH_N2N_HO_Complete| Notification from MIHF of the MN to the | | | target or source MIHF indicating the | | | status of handover completion | +--------------------+---------------------------------------------+ | MIH_N2N_HO_Complete| Notification from either source or target | | | MIHF to the peer MIHF indicating the status | | | of the handover completion | +--------------------+---------------------------------------------+ Table 3 Command Messages of MIHF Zhang, et al. Expires November 17,2018 [Page 14] Internet-Draft MIF API extension May 2017 +---------------------+--------------------------------------------+ | Messages | Description | | (Service management)| | +---------------------+--------------------------------------------+ | MIH_Capability | Discover list of Events and Commands | | _Discover | supported by MIHF | +---------------------+--------------------------------------------+ | MIH_Register | Register with a remote MIHF | +---------------------+--------------------------------------------+ | MIH_DeRegister | Deregister with a remote MIHF | +---------------------+--------------------------------------------+ | MIH_Event_Subscribe | Subscribe for MIH event notification | +---------------------+--------------------------------------------+ | MIH_Event_Unsubscibe| Unsubscribe from MIH event notification | +---------------------+--------------------------------------------+ Table 4 Service Management of MIHF 7. Security Considerations This document does not contain any security considerations. 8. IANA Considerations There are presently no IANA considerations with this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicat Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [IEEE 802.21] IEEE, "IEEE Standard for Local and Metropolitan Area Networks Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009. . [I-D.ietf-mif-api-extension] Liu, D., Lemon, T., Ismailov, Y., and Z.Cao, "MIF API consideration", draft-ietf-mif-api- extension-05 (work in progress), Feb. 2014. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Zhang, et al. Expires November 17,2018 [Page 15] Internet-Draft MIF API extension May 2017 Authors' Addresses Hongke Zhang Beijing Jiaotong University (BJTU) Beijing, 100044, P.R.China Email: hkzhang@bjtu.edu.cn Fei Song Beijing Jiaotong University (BJTU) Beijing, 100044, P.R.China Email: fsong@bjtu.edu.cn Boxin Du Beijing Jiaotong University (BJTU) Beijing, 100044, P.R.China Email: 10291070@bjtu.edu.cn Mi Zhang Beijing Jiaotong University (BJTU) Beijing, 100044, P.R.China Email: 13120174@bjtu.edu.cn Zhang, et al. Expires November 17,2018 [Page 16]