# Faudistic Platooning: Subdivide Platoons, Unite Networks, and Conquer Efficiency and Reliability
## 4 Feudalistic Platooning
### Synchronization  
Data needed to perform _Feudalistic Platooning_ are locally stored by each vehicle in a _FeudalMap_ (see Figure 5). In order to not depend on cellular coverage or any addressing within the cellular network, we use the ad hoc network for synchronization. The synchronization process initiates and updates fields within the mentioned map. It finishes, once all vehicles have stored the required data. The vassalage is uniquely identified by its ID _vassalageld_ and the corresponding ID of the platoon _platoonId_ it belongs to. The _VassalageMap_ also contains  
Figure 4: _VassalMsg_: containing vehicle status (cams[]) and event (denms[]) data from vehicles within a certain vassalage indicated by _vassalageld_. Figure 3: _SyncMessage_: all vehicles in a platoon need to synchronize to the same request (reference) prior to perform _Feudalistic Platooning_, i.e., agreeing on _Feudalistic Platooning_ (sync[]) and sharing their LTE address (lteAddress[]). Figure 2: _FeudalMsg_: used for all ongoing communication during _Feudalistic Platooning_. The selection between _SyncMsg_ and _VassalMsg_ is context dependent and indicated by the type. the number of vehicles within the vassalage (_depth_) and their IDs and addresses (_members, lteAddresses_). _Note: members_ and _lteAddresses_ include the merchant of the preceding vassalage if there is one as well as the knight of the following vassalage, again if there is one. Their IDs and addresses need to be known once communication between vassalages based on C-V2X is considered. Neither of them is compulsory, however, for an operating feudalistic platoon. Furthermore, each vehicle selects an individual inter-vehicle distance (_ivDistancelnner_) which depends on its position within the vassalage (_innerPosition_), its role (_role_), and external circumstances considered by dynamic platooning [20]. Every time data are modified, the time stamp (_timeStamp_) is updated. As with platooning in general, _Feudalistic Platooning_ should also be decentralized. This means that required data differ from vehicle to vehicle. The platoon or a part of the platoon determines either a fixed or a variable vassalage size. Future lords, i.e., the mid vehicle of future vassalages, initiate the formation procedure by sending a _FeudalMsg_ of type ::_Init_ (see Figure 2). The message contains IDs and LTE addresses of future vassalage members, i.e., the size of the vassalage plus two: (i) the merchant from the preceding vassalage and (ii) the knight from the following vassalage, as mentioned previously. In case no preceding or following vassalage exists, the field remains empty. The IDs are known on initiation, since the vehicles need to be platooned. By contrast, the LTE addresses of other members do not need to be known. The initiator sends its LTE address in the broadcasted ::_Init_ message and keeps address fields of other members 0. By means of the LTE address, a vehicle is uniquely identified within the cellular network. Receivers of the message check if the message is of relevance, i.e., their ID is contained in the member field. If this is the case and their address was not already present in the receiving packet, they add their own address and rebroadcast the message. This ensures that messages are only present once new information is available and unnecessary flooding of the network is avoided. Furthermore, receiving vehicles check whether they are core or peripheral members:  
* Core members are lord, knight, merchant and all the peasants of the dedicated vassalage;
* Peripheral members are merchant and knight of preceding, respectively, the following vassalages. Addresses of peripheral members need to be known to exchange messages between vassalages using the C-V2X network link. In addition to adding its address and rebroadcasting the packet once new information is available, core members determine their own role within the newly founded vassalage according to their track position.