IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-08-0065-00-0000
Title: MIH State Machines Revised
Date Submitted: March 7, 2008
Presented at IEEE 802.21 session 25 in Orlando
Authors or Source(s):
Yoshihiro Ohba
Abstract: This document addresses SB recirc-2 comments #11,
#12, #13 and #14 as well as 21-08-0063-00-0000 on state
machines
21-08-0065-00-0000
1
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
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
21-08-0065-00-0000
2
Comment #11
• “The error is that the two arrows out of the init box do not
capture the condition "opcode=response && !isBroadcast" i.e., the instance for a directed response never terminates,
thereby blocking any further transmissions. The same error
occurs in figure 24.”
• Proposed resolution: “I don't know how to fix this bug,
unfortunately. Also note that the condition out of process_msg
includes "!Broadcast" when it should include "! IsBroadcast“
• Response to the commenter: Agreed in principle
• Resolution:
• This check has been incorporated into the setting rules of
MsgOutAvail and MsgInAvail variables (See resolution of
Comment #13)
• Transaction Source and Destination State Machines are
revised accordingly
21-08-0065-00-0000
3
Comment #12
• “I think the state machine would benefit from some reorganization.”
• Proposed resolution: “The "process_msg" state actually waits for a nonbroadcast message. The title is misleading. I suggest that all the waiting be
done in the "Wait response msg" state. The process message should just
process the current message and then either transition to success or back to
wait response msg. This can be achieved by replacing the transition to the
left of the process_msg with one from that to wait_response_msg
conditioned on "IsBroadcast“
• Response to the commenter: Agreed
• Resolution:
• Transaction Source and Destination State Machines are revised
accordingly
• Add the following variable in section 8.2.2.7.2:
•
•
“ResponseReceived – This variable’s type is BOOLEAN. When its value is TRUE it
indicates that a Response message has been received. Otherwise, its value is
FALSE.”
Also remove unused variable “Initialize” from Table 19, Figure 23 and
Figure 24 as part of reorganization
21-08-0065-00-0000
4
Comment #13
• “How is MsgOutAvail set to true? The only assignments I see are to set this
to false.”
• Proposed resolution: “Document in table 19 how this is set to true, or update
one or more of the state machines.“
• Response to the commenter: Agreed in principle.
• Resolution:
• Change the Description of MsgOut in Table 19 to:
•
•
“A valid outgoing message generated by the local MIHF to be sent to the remote
MIHF. An outgoing message is valid in term of state machine operation if the
message has the Operation Code of the value Request (0x1), Response(0x2) or
Indication(0x3).”
Change the Description of MsgOutAvail in Table 19 to:
•
“This variable is set to TRUE by an entity external to the state machines or by
Transaction Destination State Machine when a valid outgoing message is available
for a transaction. The transaction corresponds to an instance of Transaction Source
State Machine if the message has the Operation Code of the value Request (0x1) or
Indication(0x3), or the Operation Code of the value Response(0x2) and a broadcast
destination MIHF ID. The transaction corresponds to an instance of Transaction
Destination State Machine if the message has the Operation Code of the value
Response(0x2) and a unicast destination MIHF ID. The correspondence between an
outgoing message and a transaction is made based on matching TID, MyMihfID and
PeerMihfID variables of Transaction Source or Destination State Machine against
the Transaction ID field, Source Identifier TLV and Destination Identifier TLV of the
outgoing message, respectively. This variable is initialized to FALSE by the external
entity. It is the responsibility of the external entity to set this variable to TRUE such
that this MIH node has no more than one transaction pending for each direction with
a certain MIH peer.”
21-08-0065-00-0000
5
Comment #13 (cont’d)
• Resolution (cont’d)
• Change the Description of MsgIn in Table 19 to:
•
•
“A valid incoming message received from a remote MIHF. An incoming message is
valid in term of state machine operation if the message has the Operation Code of the
value Request (0x1), Response(0x2) or Indication(0x3).”
Change the Description of MsgInAvail in Table 19 to:
•
“This variable is set to TRUE by an entity external to the state machines when a
valid incoming message is available for a transaction. The transaction corresponds to
an instance of Transaction Destination State Machine if the message has the
Operation Code of the value Request (0x1) or Indication(0x3), or the message has
the Operation Code of the value Response(0x2) and a broadcast destination MIHF
ID. The transaction corresponds to an instance of Transaction Source State Machine
if the message has the Operation Code of the value Response(0x2) and a unicast
destination MIHF ID. The correspondence between an incoming message and a
transaction is based on TID, MyMihfID and PeerMihfID variables of Transaction
Source or Destination State Machine against the Transaction ID field, Destination
Identifier TLV and Source Identifier TLV of the incoming message, respectively.
This variable is initialized to FALSE by the external entity. This variable is set to
FALSE by the state machines once the incoming message has been processed. It is
the responsibility of the external entity to set this variable to TRUE such that this
MIH node has no more than one transaction pending for each direction with a certain
MIH peer.”
21-08-0065-00-0000
6
Comment #13 (cont’d)
• Resolution (cont’d)
•
Move TID from Table 18 to Table 19
•
Add the following variable to Table 19
•
•
•
•
Name : MyMihfID
Type : MIHF_ID
Description: The MIHF ID of this MIH node
Add the following variable to Table 19
•
•
•
Name : PeerMihfID
Type : MIHF_ID
Description: The MIHF ID of the peer MIH node
As a consequence, the following actions are NOT NEEDED within
Transaction Source and Destination State Machines and will be removed
from the state machines: (i) checking whether Response is broadcast or not,
and (ii) checking TID and MIHF-IDs
21-08-0065-00-0000
7
Comment #14
• “How do the response state machines terminate. Consider receiving a
message that is a request, which requires an ack response. In this case we
enter the WAIT_RESPONSE_PRM state. The Ack responder transmits an
ACK and waits in the RETURN_ACK state. MsgOutAvail is never set by
any state machine action that I can see. So the only exit from both of these
states is the TransactionStopWhen transition. Bottom line, we can respond
to at most one transaction per TransactionStopWhen period.”
• Proposed resolution: “These state machines are complex. The interactions
between them are subtle. I have no confidence they are correct. Please
address this comment. Also, provide (perhaps informative) examples of the
operation of these state machines, perhaps a message sequence diagrams.
(where the messages are writing to the shared variables).”
• Response to the commenter: Agreed in principle
• Resolution:
• See resolution of Comment #13
21-08-0065-00-0000
8
Other fixes (per 21-08-0063-00) – 1/5
• What is a piggybacked Ack?
• The only case when a non-Null packet “carries an ack” is the Response +
ACK_RSP case. But on receiving the response, the source transaction
completes with SUCCESS, regardless of the ACK_RSP bit setting. So
it has no effect.
• So, we could loose the ACK_RSP bit completely, and replace
Null+ACK_RSP with an opcode meaning “Ack”. I believe this would
be clearer.
• Response to the commenter: Agreed in principle
• While ACK for Response is not meaningful for the transaction source, it
is meaningful for the transaction destination to (i) cease to exist
immediately when ACK is received and (ii) fail when ACK is not
received.
• Resolution:
• Instead of replacing NULL+ACK_RSP with a new opcode “Ack”, revise
Transaction Destination State Machine to realize functions (i) and (ii)
described above.
21-08-0065-00-0000
9
Other fixes (per 21-08-0063-00) – 2/5
• Delayed Ack Response is too complicated
•
A possibly unnecessary function is the delayed ack response detection through a timeout.
This is clearly designed to allow access to remote data or such in the response. Perhaps a
cleaner alternative which avoids the timeout is to have the transaction client indicate to the
transaction destination state machine synchronously that a response is available or will be
available after some delay. The ack can then be generated immediately in the case of a
delayed response, rather than after some timeout
• Response to the commenter: Agreed
• Resolution:
• Revise ACK Responder State Machine to use MsgOutAvail to determine
whether ACK is delayed or not
• Change the defintion of Process() function in Section 8.2.2.4 as follows:
•
•
•
•
•
“BOOLEAN Process(MIH_MESSAGE) - This procedure processes the incoming
message passed as an input variable. A value of TRUE is returned if an outgoing
message is available in response to the incoming message. Otherwise, a value of
FALSE is returned.”
Remove DelayedAckWhen variable from Table 18
Remove GetAckDelay() function from Section 8.2.2.7.2
Remove AckDelayTime variable from Section 8.2.2.8.1
Revise Annex E to remove all MIB objects and descriptions related to
ACK delay time
21-08-0065-00-0000
10
Other fixes (per 21-08-0063-00) – 3/5
• MsgOut.TID used after MsgOut released
• “MsgOut.TID is read on the exit from
WAIT_RESPONSE_MSG state, long after the
MsgOutAvail flag has been reset. This needs to be replaced
with reference to a local copy.”
• Resolution: Remove “MsgOutAvail=FALSE” from INIT
state
• Duplicate response transmissions don’t carry ACK_RSP
• In the PIGGYBACKING state, the Ack Responder has the
following two lines: “DUP=MsgOut;
MsgOut.ACK_RSP=1;” Assuming that the ACK_RSP is
what carries the ACK, any subsequent “Transmit(DUP)”
does not carry the ACK_RSP flag set to 1.
• Resolution: “MsgOut.ACK_RSP=1; DUP=MsgOut;”
21-08-0065-00-0000
11
Other fixes (per 21-08-0063-00) - 4/5
•
More on instancing the ACK Responder state machine
•
The ACK Responder s/m only enters the SUCCESS state on a timeout
•
•
•
•
•
•
Problem: A new peer-initiated transaction cannot be generated until transaction timeout
The intent is "clearly" that when the transaction Destination state machine exits with a SUCCESS status, the
ACK responder ceases to exist
But look at the state machines. This actually means that the ack responder gets cancelled before it can ever send
an ack. Not very useful.
What we need are persistent state machines, one per link instance. Then the subtleties hidden by the unstated and
difficult to realize instancing rules are exposed. Then the Ack Responder can hang around to generate Ack
responses to duplicate response frame transmissions until the start of the next transaction. This is the solution I
identified in my simulation.
Resolution:
•
•
Revise ACK Responder State Machine to remove SUCCESS state
Add the following sentence to Section 8.2.2.7.3:
–
•
Add the following sentence to Section 8.2.2.7.4:
–
•
“An instance of ACK requestor state machine can cease to exist once the
AckRequestorStatus is set to either SUCCESS or FAILURE state or its
associated transaction source or transaction destination state machine ceases
to exist.”
Add the following sentence to Section 8.2.2.8.4:
–
•
“An instance of transaction destination state machine can cease to exist once
the value of TransactionStatus is set to either SUCCESS or FAILURE.
Add the following sentence to Section 8.2.2.8.3:
–
•
“An instance of transaction source state machine can cease to exist once the
value of TransactionStatus is set to either SUCCESS or FAILURE.”
“An instance of ACK responder state machine can cease to exist once its
associated transaction source or transaction destination state machine ceases
to exist.”
Remove the following sentence from Section 8.2.2.8.4:
–
21-08-0065-00-0000
“This state machine terminates when it transits to SUCCESS state.”
12
Other fixes (per 21-08-0063-00) - 5/5
• More on managing the Ack state machine instances
•
The StartAck* variables are used both as levels in the transaction state machines
and as events to trigger the ack state machines. It would have been preferable to
set in the transaction state machines and reset in the ack state machines to give a
positive acknowledgement that the event has been seen. Because it is necessary
to ensure that the Ack state machines are reset at the *start* of the next
transaction (see previous comment), a new pair of variables ResetAck* were
created (set by transaction s/m, reset by ack s/m) to manage this reset.
• Resolution
• Remove AckFailure variable from Table 18.
• Add the following inter-state-variable to Table 18:
•
•
•
•
•
•
Name: AckRequestorStatus
Type: ENUMERATED
Description: Indicates the status of ACK requestor state machine. This variable is
initialized by transaction source state machine or transaction destination state
machine and changed by ACK requestor state machine.
The following values are valid:
1 ONGOING
2 SUCCESS
3 FAILURE
Revise the Transaction Source and Destination State Machines to use
AckRequestorStatus variable
Note1: ENUMERATED data type is used instead of BOOLEAN to be able to indicate ONGOING,
SUCCESS or FAILURE instead of FALSE(ONGOING) or TRUE(DONE).
Note2: AckRespondorStatus is not needed since Transaction Source and Destination State Machines do not
care whether the peer has received ACK.
21-08-0065-00-0000
13
Other fixes (Miscellaneous) – 1/2
• StartAckRequestor and StartAckRespoder needs to be
initialized to FALSE by external entities not by Transaction
Source and Destination State Machines
• Resolution
• Move StartAckRequestor and StartAckRespoder from Table
18 to Table 19, and change the Desription as follows:
•
•
Description of StartAckRequestor: “This variable is initialized to FALSE
by an external entity. The instance of ACK-requestor state machine is
started when this variable is set to TRUE by its associated transaction
source or destination state machine.”
Description of StartAckResponder: “This variable is initialized to
FALSE by an external entity. The instance of ACK-responder state machine
is started when this variable is set to TRUE by its associated transaction
source or destination state machine.”
21-08-0065-00-0000
14
Other fixes (Miscellaneous) – 2/2
• The following text in Section 8.2.2 only talks about outgoing
transaction and does not cover incoming transaction:
• “At any given moment, the source MIH node shall have no
more than one transaction pending with a certain MIH peer.
In other words, the source MIH node has to wait until any
pending transaction is completed before it initiates another
transaction with the same peer.”
• Resolution
• Change the text as follows:
•
“At any given moment, an MIH node shall have no more than one
transaction pending for each direction with a certain MIH peer. In other
words, the MIH node has to wait until any pending outgoing transaction is
completed before it creates another outgoing transaction for the same peer.
Similarly, the MIH node has to wait until any pending incoming transaction
is completed before it creates another incoming transaction for the same
peer.”
21-08-0065-00-0000
15
Transaction Source State Machine (revised)
INIT
TransactionStatus=ONGOING;
ResponseReceived=FALSE;
TransactionStopWhen=TransactionLifetime;
MsgOutAvail
Opcode=MsgOut.OPCODE;
Transmit(MsgOut);
(Opcode==Indication
&& !StartAckRequestor) ||
Opcode==Response
IsBroadcast:=IsBroadcastMsg(MsgOut);
StartAckRequestor=(MsgOut.ACK_REQ==1?TRUE:FALSE) && !IsBroadcast
TID=MsgOut.TID
MyMihfID=SrcMIF_ID(MsgOut);
PeerMihfID= DstMIHF_ID(MsgOut);
Opcode==Request
WAIT_RESPONSE_MSG
Opcode==Indication &&
StartAckRequestor
!ResponseReceived &&
TransactionStopWhen== 0
ResponseReceived &&
TransactionStopWhen==0
FAILURE
WAIT_ACK
AckRequestorStatus=ONGOING
TransactionStatus=FAILURE
AckRequestorStatus==FAILURE
MsgInAvail
IsBroadcast
PROCESS_MSG
StartAckResponder=
(MsgIn.ACK_REQ == 1 ? TRUE : FALSE);
Process(MsgIn);
MsgInAvail=FALSE;
AckRequestorStatus==SUCCESS
SUCCESS
ResponseReceived=TRUE
! isBroadcast
TransactionStatus=SUCCESS
21-08-0065-00-0000
16
Transaction Destination State Machine (revised)
INIT
TransactionStatus = ONGOING;
(Opcode,MID,TID)=MsgIn.(OPCODE,MID,TID);
TransactionStopWhen=TransactionLifetime;
MsgInAvail
PeerMihfID=SrcMIHF_ID(MsgIn);
MyMihfID=DstMIHF_ID(MsgIn);
StartAckResponder=(MsgIn.ACK-REQ==1 ? TRUE : FALSE) && !IsBroadcast;
MsgOutAvail=Process(MsgIn);
MsgInAvail=False;
Opcode==Request
WAIT_RESPONSE_PRM
FAILURE
TransactionStopWhen==0
TransactionStatus = FAILURE
Opcode==Indication ||
Opcode ==Response
MsgOutAvail&&
(!StartAckResponder ||
MsgOut.ACK-Rsp==1)
AckRequestorStatus==FAILURE
SEND_RESPONSE
StartAckRequestor=(MsgOut.ACK-Req==1 ? TRUE : FALSE);
AckRequestorStatus=ONGOING;
Transmit(MsgOut);
!StartAckRequestor || AckRequestorStatus==SUCCESS
SUCCESS
TransactionStatus = SUCCESS
21-08-0065-00-0000
17
ACK Requestor State Machine (revised)
StartAckRequestor
INIT
RtxCtr=0;
UCT
RetransmissionWhen==0&&
RtxCtr<RtxCtrMax
WAIT_ACK
RetransmissionWhen=RetransmissionInterval;
UTC
RETRANSMIT
Transmit(MsgOut);
RtxCtr++
MsgInAvail&&
MsgIn.ACK_RSP==1
RetransmissionWhen==0 &&
RtxCtr==RtxCtrMax
SUCCESS
AckRequestorStatus=TRUE;
21-08-0065-00-0000
FAILURE
AckRequestorStatus=FALSE;
18
ACK Responder State Machine (revised)
INIT
ACK.ACK_REQ=0; ACK.ACK_RSP=1;
StartAckResponder
ACK.(MID, TID)=(MID,TID);
SrcMIHF_ID(ACK)=MyMihfID;
DstMIHF_ID(ACK)=PeerMihfID;
MsgOutAvail
!MsgOutAvail
MsgInAvail
RETURN_ACK
Transmit(ACK);
MsgInAvail=FALSE;
MsgOutAvail
PIGGYBACKING
MsgOut.ACK_RSP=1;
DUP=MsgOut;
MsgInAvail
RETURN_DUPLICATE
Transmit(DUP);
MsgInAvail=FALSE;
MsgInAvail
21-08-0065-00-0000
19