Which microcontroller should be master / slave?
Is there a rule to determine who will be [I2C] slave / master?


Yes. Only an I2C master can start a transmission. An I2C slave cannot tell you about something, until it is next polled by the master (unless you add extra interrupt signals, which increases overall system complexity).

Ignoring the (rarely-used) feature for a device to switch between being a master and a slave, this means that the I2C master must have enough knowledge of the overall system, to know how to communicate with all of the I2C slaves on that bus.


  What question should I ask myself to make the good choice? (in general, not for this specific system)


Think about which MCU in your system knows:


most about overall system state, and can therefore decide when to send I2C commands to the slaves;
which I2C commands need to be sent to each slave;
what data needs to be collected from each I2C slave;
which I2C devices purely respond to incoming commands (this will apply to your "S1" MCUs - it seems clear that they are most suited to being slaves);


Irrespective of which MCU is going to be the I2C master, you need to design the overall system architecture and consider which commands need to be sent to each device, and how quickly any responses need to be received. Try to design a system which does have an obvious "master" and knows all system state, and then it can likely be the I2C master device too.

You said:


  S3 is the center of the system but in the other hand, S2 may send more message than S3.


It isn't clear who "S2" is sending messages to. Does it need to actively send messages to anyone? Or can "S2" be polled by "S3" as I2C master, to receive whatever sensor and switch information "S2" collects? If "S2" can be polled by "S3" then, on the basis of the description, it seems clear that "S3" MCU could be the I2C master.

I am cautious about adding yet another MCU (let's call it "S10") to be the I2C master. That's because it seems that an "S10" MCU would need to do lots of polling, just to gather overall system state knowledge which is all (?) already known by "S3". That seems like unnecessary duplication.

Therefore unless "S3" cannot do the job due to reaching its limits of RAM space, Flash space, or CPU cycles etc. it may be less complicated to have "S3" control the system by making it I2C master, rather than adding an additional "S10" controller.

On the other hand, if you don't mind the additional complexity, adding an overall "S10" controller increases the modularity (segmentation) of the system, since "S3" then only does Bluetooth and audio - nothing else. This could allow extra flexibility for adding new (unforeseen) features / additional MCUs in future, without needing to change the code in "S3".