In general, the ranges of command codes that are defined for Vendor or Standards use in Table 16 in Section 5.1.9.3 (i.e., the main table that defines the I3C Common Command Codes) can be used by any implementer or any standards developing organization to define custom CCCs that extend I3C to accommodate new use cases. However, the definition of custom CCCs should be considered carefully, as the practical issues of implementation might lead to situations where interoperability could be affected, across multiple I3C Slave Devices that interpret the same command code differently.

For example, different implementers or standards groups might define a custom CCC using the same command code (i.e., byte value for the CCC) with different interpretations of the message format that their custom Slave Device should return, for a Direct GET CCC; or different expectations about how their custom Slave Device should act, for a Direct SET CCC; or different expectations about which Defining Bytes might be supported for this CCC, for their custom Slave Device. For these conflicting definitions, interoperability issues would certainly arise if the Master used this custom CCC on an I3C Bus that used custom Slave Devices from multiple implementers, or custom Slave Devices that conformed to different standards published by several such standards groups. The Master would not necessarily have knowledge of this situation until it detected protocol issues or encountered other errors.

To help alleviate this situation, I3C v1.1 adds a new SETBUSCON CCC (see Section 5.1.9.3.31) that allows the Master to set the Bus context. This CCC informs Slaves about which version of I3C is used on the Bus, and whether it is a standards-based Bus, and/or a Vendor-private Bus. This information allows the Slave to coordinate its interpretation of extended CCCs, as well as other uses of the Bus, to match the actual current Bus context. The SETBUSCON feature is fully optional, but provides a powerful way to align standards-group-based uses of I3C with coordinated private uses. To foster proper coordination, SETBUSCON Context Byte values are published on the MIPI Alliance public website

[MIPI11] , and may be assigned by request.

MIPI Alliance strongly recommends that standards groups utilize the SETBUSCON CCC to prevent such interoperability issues, by requesting an assigned Context Byte for their particular usage, which might include a specific interpretation of any command codes that are defined for Vendor or Standards use. Additionally, such custom Slave Device implementations should not enable this custom interpretation by default, until they receive the SETBUSCON CCC with an assigned Context Byte from the I3C Master.

MIPI Alliance offers a similar recommendation to implementers seeking to define custom CCCs for private use in a custom Slave Device, by using similar logic in such a Slave implementation to not enable this custom interpretation by default, until receiving the SETBUSCON CCC with a suitable Context Byte from the I3C Master to explicitly enable a private interpretation.

FAQ Type: 
I3C