In IEC61850-6 and IEC61850-7-2, the segmentation no longer supported in Ed.2.
While in IEC61850-8-1 Table62, the segmentation is still existing and in Table 64, it was used to decide the presentation of "SubSeqNum " and "MoreSegmentsFollow".
Proposal
1. The segmentation shall be dropped from Table 62.
2. The "SubSeqNum" and "MoreSegmentsFollow" shall be decided by OptFlds.sequence-number as described in IEC61850-7-2 Table 38.
3. The following text (61850-8-1 2011-06 p76) must also be removed :
The segmentation bit is reserved in order to keep OptFlds and ReportedOptFlds in alignment.
4. The following text must be updated (61850-8-1 2011-06 p78):
The segmentation bit shall be used to indicate the presence or absence of the SubSeqNum and the MoreSegmentsFollow access-result.
If the segmentation bit is TRUE, then the SubSeqNum and MoreSegmentsFollow AccessResults shall be present. If the segmentation bit is FALSE, the SubSeqNum and MoreSegmentsFollow AccessResults shall not be present.
Discussion
Created
Status
12 Apr 13
In Force (green)
not accepted
05 Mar 13
Ballot Period
8-1 defined the ReportedOptionFields option vs the OptionFields
Using segmentation allows the server to send the moreSegmentFollow and subSequenceNumr when it realizes that the report does not fit in a single message.
In case it does fit in a single message, it is not included.
Using the OptFlds.sequence-number as specified in 7-2 would force to send the two parameters independently if the message fit a telegram or not.
It was not the intention in 8-1:2003, and is still not the intention in 8-1:2007.
Additionaly, such a change would lead to a major backward compatiblity issue.