1030   OptFlds.segmentation in BRCB/URCB and Report format(SubSeqNum and MoreSegmentsFollow presence)

Created: 01 Mar 2013

Status: In Force (green)

Part: Part 8-1 (2011; Edition 2)


Page: 76, 78

Clause: Table 62, 64


Category: Issue for edition 2 of this part


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".


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.
04 Mar 13 Discussion (red)


Privacy | Contact | Disclaimer

Tissue DB v.