Presentation is loading. Please wait.

Presentation is loading. Please wait.

21-07-0302-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0302-00-0000 Title: MIH State Machines Representation Date Submitted: October 2007.

Similar presentations


Presentation on theme: "21-07-0302-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0302-00-0000 Title: MIH State Machines Representation Date Submitted: October 2007."— Presentation transcript:

1 21-07-0302-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0302-00-0000 Title: MIH State Machines Representation Date Submitted: October 2007 Presented at IEEE 802.21 ad-hoc meeting, Murray Hill, NJ Authors or Source(s): Yoshihiro Ohba, Miriam Tauil Abstract: This document propose resolution to SB comments related to the MIH state Machines.

2 21-07-0302-00-00002 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html

3 21-07-0302-00-00003 State Machine SB Comments This contribution is mainly driven by SB comment 11 and its suggested remedy. Comment 11: The MIH protocol is inadequately specified. In particular, the state machine is overly simplified, and none of the state variables are rigorously or formally defined. Comment 11 Suggested Remedy: Include a formal specification of the MIH protocol, either as a completely defined state machine (in the manner of IEEE 802.3), a reference code specification (in the manner of IEEE 802.1), or a formalized language (in the manner of IEEE 802.11). Also addresses the following comments..

4 21-07-0302-00-00004 Additional SB Comments: Retransmission in the state machines diagrams Comments 568, 569 Figure 22/24: The state diagram in Figure does not match the description in the text. More specifically, the state diagram does not show that retransmission shall happen only twice. Note that the IEEE SA has ruled that state diagrams are normative, which means that the state diagram must be correct. Comments 56, 57, 58- p. 145, l. 34, 8.2.2.1/2/3 The text states a transition from SENDING to INIT after two (unsuccessful) retransmission but the state machine does not reflect this. Text states that max. 2 retransmissions are allowed but the state machine does reflect this

5 21-07-0302-00-00005 Additional SB Comments: Retransmission – why 2 times? Comment 231: There seems to be arbitrary decisions made regarding the MIH Protocol Acknowledgement operation. For example, why re-transmit only 2 times? Such variables are usually expressed in a MIB. What about the possibility of aggregated Ack messages? Suggested Remedy: Restrict description of MIH Acknowledgement operation to the messages exchange. Implementation details should be left out or else in the Annex Comment 2 : "The source MIH node may at most make two retransmission attempts in addition to the first attempt for an MIH protocol message with the same Message-ID and the same Transaction-ID.“ What's special about "two"? Why this embedded magic number? This depends on the properties of the link, and couples the protocol to assumptions about the medium. Suggested Remedy: Make this number a property of the link type.

6 21-07-0302-00-00006 Additional SB comments Error condition transitions in the state machines- Comment 336- p145 What if a source node can not receive any answer even it sent a REQ? and also what if a destination node can not give any response even if it receives a REQ? Therefore, I suggest all states except INIT should have transition to INIT when the transaction time expires. Make transition to INIT in all states when the transaction time expires, page 145-146. Capability Discover Comment 193: page 154 line 5 The broadcasting of this message cannot be consumed by any of the state diagrams in 8.2. New state machines need to be added to permit transmission and reception of this very special case. None of the current state diagrams can be used because they all include the ack/rep bit behavior, which cannot be used in these cases. Add new state diagrams, or remove this capability and any associated material from the entire draft. Comment 338: There is no transaction state diagram for broadcast MIH_Capability_Discover message. Refer to contribution, 21-07-0316-00-0000-MIH_Capability_Discovery

7 21-07-0302-00-00007 State Machines Transaction Source State Machine Transaction Destination State Machine ACK-requestor State Machine ACK-responder State Machine ACK-requestor State Machine ACK-responder State Machine ACK/Retransmission Handling OpCode specific Handling Remote Interaction via MIH protocol Local Interaction via global variables

8 21-07-0302-00-00008 Variable Types NameAttributes MessageAttributesTypeRangeDescription ACK-ReqInteger:1[0,1]ACK request bit. Initialized to 0. ACK-RspInteger:1[0,1]ACK response bit. Initialized to 0 MIDMessage- ID N/AMessage Identifier TIDInteger:16[0,2^16-1]Transaction Identifier Variable- Part StringN/AVariable Part (optional) NameAttributes Message- ID NameTypeRangeDescription SIDInteger:4[1,4]Service Identifier OpcodeInteger:2[1,3]Operation AIDInteger:10[1,1023]Action Identifier NameTypeRangeDescription BooleanEnumerate{TRUE,FALSE}Logical 1 (TRUE) or 0 (FALSE)

9 21-07-0302-00-00009 Global Variables NameTypeRead/Write /Export Description MsgInMessageR/EIncoming Message MsgInAvailBooleanR/W/EIndicates if there is an incoming message for the transaction. Initialized to FALSE. MsgOutMessageR/EOutgoing Message MsgOutAvailBooleanR/EIndicates if there is an outgoing message for the transaction. Initialized to FALSE. OpcodeIntegerR/WAn Opcode TIDIntegerR/WA transaction identifier MIDIntegerR/WA message identifier StartACKRequestorBooleanR/WIndicates if ACK requester state machine is started. StartACKResponderBooleanR/WIndicates if ACK responder state machine is started. AckFailureBooleanR/WIndicates if ACK operation failed TransactionTimeoutBooleanR/WA timer to cancel transaction Exported variables are writable from entities that use the state machines defined in this document.

10 21-07-0302-00-000010 Local Variables NameTypeWithinDescription BroadcastBooleanTr. Src/DstIndicates whether a message has a broadcast destination address. DUPMessageACK Responder A message which has already been sent ACKMessageA message with a null variable load and ACK-Rsp bit set DelayedAckTimeoutBooleanA timer to delay ACK RetransmissionTimeoutBooleanACK Requestor A timer to retransmit a message RetransmissionIntervalIntegerThe delay value for delayed ACK RtxCtrIntegerRetransmission Counter RtxCtrMaxIntegerMaximum number of retransmission

11 21-07-0302-00-000011 Functions NameInputOutputDescription NewTID()VoidIntegerOutput a new Transaction Identifier StartTimer()BooleanVoidStart a timer associated with the boolean input variable. The boolean input variable is initialized to false. After a time period specified in the integer input variable, the boolean input variable is set to True. Integer StopTimer()BooleanVoidStop a timer corresponding to the input variable. Process()MessageVoidProcess an incoming message Transmit()MessageVoidTransmit a message. BroadcastMsg()MessageBooleanOutput TRUE if the input message has a broadcast destination MIHF ID. Otherwise output FALSE. GetAckDelay()Integer Compute the time duration for delaying an ACK using MID of a message. Especially the output value is always zero (0) if MID.Opcode==indication or MID.Opcode==response. If MID.opcode==request, the time duration for delaying the ACK may depend on MID.SID and MID.AID.

12 21-07-0302-00-000012 Conventions State machine conventions defined in IEEE 802.1X are used in this document State transitions occur upon a change in values of variables UCT (Unconditional Transition) is a special boolean variable which always has a TRUE value The action specified inside each state box is executed when entering the box (not when exiting the box)

13 21-07-0302-00-000013 Transaction Source State Machine INIT MsgOutAvail=MsgInAvail=FALSE; StartAckRequestor=StartAckResponder=FALSE; AckFailure=FALSE; StartTimer(TransactionTimeout, TransactionLifetime); Opcode=MsgOut.MID.Opcode; MsgOut.TID=NewTID(); Transmit(MsgOut); StartAckRequestor=(MsgOut.ACK-Req==1?TRUE:FALSE); Broadcast=BroadcastMsg(MsgOut); MsgOutAvail=FALSE; WAIT_RESPONSE_MSG SUCCESS FAILURE TransactionTimeout || AckFailure MsgOutAvail MsgInAvail&& MsgIn.TID==MsgOut.TID PROCESS_MSG StartAckResponder= (MsgIn.ACK-Req == 1 ? TRUE : FALSE); Process(MsgIn); MsgInAvail=FALSE; ! Broadcast || TransactionTimeout Opcode==Request Opcode==Indication || ( Opcode==Response && Broadcast ) MsgInAvail&& MsgIn.TID==MsgOut.TID&& Broadcast Send unsolicited broadcasted responses Receive responses to broadcasted request

14 21-07-0302-00-000014 Receive unsolicited broadcasted responses Transaction Destination State Machine INIT StartAckResponder=StartACKRequestor=FALSE; (Opcode,MID,TID)=MsgIn.(Opcode,MID,TID); StartTimer(TransactionTimeout, TransactionLifetime); Process(MsgIn); StartAckResponder=(Msg.ACK-Req==1 ? TRUE : FALSE); Broadcast=BroadcastMsg(MsgIn); MsgInAvail=FALSE; SUCCESS MsgInAvail FAILURE TransactionTimeout SEND_RESPONSE StartAckRequestor=(MsgOut.ACK-Req==1 ? TRUE : FALSE); MsgOut.TID=MsgIn.TID; Transmit(MsgOut); WAIT_RESPONSE_PRM MsgOutAvail&& (!StartAckResponder || MsgOut.ACK-Rsp==1) Opcode==Indication || (Broadcast && Opcode ==Response) Opcode==Request UCT

15 21-07-0302-00-000015 ACK Requestor State Machine INIT RtxCtr=0; WAIT_ACK StartTimer(RetransactionTimeout, RetransmissionInterval); SUCCESSFAILURE AckFailure=TRUE; MsgInAvail&& MsgIn.ACK-Rsp==1&& MsgIn.TID==MsgOut.TID RetransmissionTimeout&&RtxCtr==RtxCtrMax StartAckRequestor RETRANSMIT Transmit(MsgOut); RtxCtr++ RetransmissionTimeout&& RtxCtr<RtxCtrMax UCT

16 21-07-0302-00-000016 ACK Responder State Machine RETURN_ACK Transmit(ACK); MsgInAvail=FALSE; DELAYING_ACK StartTimer(DelayedAckTimeout, AckDelayTime); AckDelayTime>0 MsgOutAvail DelayedAckTimeout PIGGYBACKING DUP=MsgOut; MsgOut.ACK-Rsp=1; AckDelayTime==0 INIT ACK.ACK-Req=0; ACK.ACK-Rsp=1; ACK.(Opcode, MID, TID)=(Opcode,MID,TID); AckDelayTime=GetAckDelay(MID); StartAckResponder MsgInAvail MsgOutAvail MsgInAvail RETURN_DUPLICATE Transmit(DUP); MsgInAvail=FALSE; MsgInAvail SUCCESS TransactionTimeout

17 21-07-0302-00-000017 References 1.IEEE Std 802.1X™-2004 – Port-Based Network Access Control


Download ppt "21-07-0302-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0302-00-0000 Title: MIH State Machines Representation Date Submitted: October 2007."

Similar presentations


Ads by Google