The cross-layer collaboration aims at improving processing efficiency by exchanging the control information among layers. We are proposing a cross-layer architecture called CEAL (Cross-layer control information Exchange between Arbitrary Layer) [RFC 5184]. CEAL allows control information exchange between arbitrary layers with keeping the layered structure. In CEAL, the control information in a layer is exchanged between layers after it is transformed from protocol/device-dependent representation into protocol/device-independent representation.
CEAL enables, for example,
- fast handover in the network layer by the collaboration of the link layer and the network layer [L3-FHOX] and
- fast failover and fast handover in SCTP by the collaboration of the link layer, the network layer, and the transport layer [SCTPfx, SCTPmx].
Thus, receiving the benefit of the layered model, it is possible to realize flexible processing by a clearly defined cross-layer architecture for control information exchange among layers.
The information in each layer should be abstracted before it is sent to another layer. For example, in IEEE 802.11, the Received Signal Strength Indicator (RSSI), the number of retransmissions, and the existence of association between the mobile node and the access point are used so that the link layer indications can adjust themselves to various environments or situations.
In the conventional protocol-layering model, the Protocol Entity (PE) is defined as the entity that processes a specific protocol. CEAL introduced the Abstract Entity (AE) to achieve link independency of the link indications as shown in Figure 1. An AE and a PE make a pair. An AE abstracts the PE-dependent information to the PE-independent information.
Each layer offers its services in the form of primitives. Four classes of primitives are defined, as shown in Figure 2. Request is issued by the layer that wants to get the services or information from another layer, and Confirm is the acknowledgment of the request. Indication is the notification of the information to the layer that requested the service, and Response is the acknowledgment of the indication. In this architecture, communication between layers is symmetrical.
Three Types of Primitive Usage
In CEAL, three different usages of primitives are defined as shown in Figure 3.
- Type 1: to get information of the target layer immediately
The Request and Confirm classes of primitives are exchanged for the interaction. The Request primitive is for an acquisition request for the information of the target layer. The Confirm primitive is for the answer.
- Type 2: to notify another layer of events in the target layer asynchronously
The Request, Confirm, and Indication classes of primitives are exchanged for the interaction. The Request and Confirm primitives are used just for registration. When an event occurs, the Indication primitive is asynchronously delivered to the calling layer.
- Type 3: to control the action of the target layer from another layer
The Request and Confirm classes of primitives are exchanged for the interaction. The Request primitive is a request for operation. Ack or Nack returns immediately as the Confirm primitive.