Reviewing the Service Specification of the Ieee 802.16 Mac Layer Connection Management: a Formal Approach

In most of the communication protocol specification documents, there is little, if any, use of more formal techniques for specifying the protocols, such as state and service primitive tables. Thus, these documents are sometimes ambiguous, difficult to understand, and imprecise. The IEEE 802.16 standard document is responsible for specifying and describing the air interface of the BWA systems (Broadband Wireless Access Systems) point to multipoint fixed and mobile networks, and is limited to the description of the MAC(Medium Access Control) layer and physical (PHY). Since the MAC layer is connection-oriented, the standard defines how the connection management service is provided. The service is specified as the occurrence of a set of well-defined service primitives. However, the description of the service specification is somehow informal and presents some ambiguities and inconsistences. So in this paper, we describe the omissions, uncertainties and discrepancies found in the standard documents and propose some solutions to fix these problems. We also provide a formal description of the connection management service specification using Finite State Automata (FSA).


Introduction
WiMax is a wireless technology for metropolitan area networks that was developed by the IEEE Working Group 802.16 [1].This technology provides an alternative to cable access networks such as fiber optic links and digital subscriber lines (DSLs).Compared to its competitor cable technologies, WiMax is easier to deploy and is poised for more ubiquitous broadband access in the future.WiMax users (subscriber stations, SS) access the network through exterior networks communicating with central radio base stations (BS).The IEEE 802.16 protocol stack includes two layers: the physical and MAC layers.The MAC layer is connection-oriented, so all the services including connectionless services are mapped to a connection.Thus, the standard defines the connection management procedures and how the service is provided to the upper layer protocol [1] [2].
The service specification describes the service that is provided to the user.This is often given as a sequence of events that are possible at an abstract interface between the user (an application or another protocol) and the protocol.The communication between adjacent layers can be described at an abstract level through the occurrence of the service primitives, which provide an abstract way to describe the interaction between the service user and the service provider.The service specification is defined at a higher level of abstraction than the protocol specification and can be described in the protocol specification document or in a separate one [3].The IEEE 802.16 MAC layer connection management service specification is described in the standard document [1].The specification explains the service by using narrative and some event sequence diagrams.However, does not impose message formats or state machines for the use of these primitives [1].Thus, this lack of formalism in describing the service specification may lead to ambiguity and inconsistency which may cause possible errors in the implementation of the MAC layer protocol.Our first attempt at modeling and analysis of the MAC CPS connection management service specification is presented in [14], where a formal and detailed description of the service specification given.The analysis results of the model of the service specification show some inconsistencies and information gaps in the standard document.Thus, this paper describes the omissions, ambiguities and inconsistencies observed in the standard, and propose some solutions to fix these problems.We also provide a formal description of the connection management service specification using Finite State Automata (FSA).
Coloured Petri Nets (CPNs) are a formal technique used for modelling many systems, particularly communication protocols [4][5] [6][7] [8].Billington et al. [5] present a methodology for specifying and validating communication protocols and show some example of how the methodology can be applied using CPNs.In the methodology, the specification process is divided into: the service specification and protocol specification.We use the formal approach proposed by Billington [5] to describe the IEEE 802.16 MAC layer connection management service specification.
The paper is organised as follows.Section 2 presents a description of the IEEE 802.16 standard.Section 3 explains briefly the protocol verification methodology proposed by Billington.Section 4 describes the IEEE 802.16 MAC layer connection management service specification.Section 5 presents some relevant aspects of the service specification based on the application of the methodology.And finally in Section 6 concludes the papers and show some future directions of the work.

An Overview of IEEE 802.16
The IEEE 802.16 standard is responsible for specifying and describing the air interface for Broadband Wireless Access (BWA) systems for fixed and mobile users and is limited to the description of the MAC and PHY layers.The initial version of the IEEE 802.16 standard was completed in October 2001 [1] and its main goal was to provide broadband wireless access.It was also developed to provide support for mesh topologies and provide handoff (handover) of the signal between base stations [9] [10].
The standard was designed to accommodate a set of air interfaces based on a common MAC protocol but with different physical layer specifications depending on the use of radio spectrum and the regulations associated with them [1] [2].

Components of the IEEE 802.16 Architecture
The IEEE 802.16 standard specifies the basic entities in the architecture (see Figure 1).They are described as follows: Subscriber Station (SS): is a generalized device which provides connectivity between a suscriber equipment and a base station and includes some entity instances of the MAC and PHY layers.

Mobile Station (MS)
: is an optional entity defined in the later versions of the IEEE 802.16 standard document [9] [10] and includes some additional capabilities to support vehicular mobility.It also provides additional support for specific functions such as SS handoff management and energy saving.Thus the MS delivers the functionalities for supporting both wireless broadband fixed and mobile users.

Reference Model
The IEEE 802.16 Reference Model includes two major components: the data/control plane and the management plane [1][9] [10].The data/control plane includes two layers: the physical and MAC layers.The MAC layer is further divided in three sub-layers: Service Specific Converge Sublayer (CS), MAC Common Part Sublayer (MAC CPS), and Security Sublayer (see Figure 2).The control and data planes define how the information is encapsulated or desencapsulated at the MAC level, and modulated or demodulated at the physical level.The functions of the management plane are: classification, security, application QoS and connection settings among others.The layers are described as follows:  Common Part Sublayer (MAC CPS): is responsible for controlling the access to the medium.The other basic functions of the MAC CPS layer are data encapsulation/de-encapsulation, and data packing and fragmentation.It is also responsible for data control error (error detection and retransmission strategy).Additionally, this provides mechanisms for traffic control and QoS provision.The MAC layer is connection-oriented, so all the services including connectionless services are mapped to a connection.
 Security Sublayer: is responsible for delivering privacy to subscribers in the wireless network.It provides authentication and secure key exchange and encryption on the connections established between the either a SS or a MS and the BS.
 Physical Layer (PHY): defined to work on the 10-66 GHz band.It supports adaptive burst profiling in which some transmission parameters, such as modulation and coding schemes, may be changed on either a perconnection or per-subscriber basis to adapt to channel changing conditions and to provide varying levels of service.Time Division Duplexing (TDD) and Frequency Division Duplexing (FDD) techniques are supported.The data encapsulated in MPDUs are carried in TDD or FDD PHY frames

Connection Management
The MAC CPS is connection-oriented, so a connection must be established between peer convergence processes.Once a connection is established, it may require to be maintened.Maintenance activities are needed, for example, to deal with dynamic bandwidth requirements.Finally, a connection may be terminated by either the BS or SS.
Management activities of connections are supported through a set of service primitives between the entities of the MAC CS and CPS implemented in both the SSs and the BS.Some aspects of the connections are described as follows [1] [11]:  Connection establishment: after a SS register with the BS, the transport connections are established.Each connection is associated with a service flow and defines the relationship between the CS peer entities that use this MAC service flow.Additionally, new connections can be established in order to change the established characteristics of a client service.
 Changes of the connection characteristics: once a connection is established it may need to be actively maintained.Maintenance requirements vary according to the type of service.The modification of the connections may require maintenance stimulated by the SSs or the network connection (BS).
 Connection termination: connections can be terminated.The termination of a connection can be initiated by either the BS or the SS.
The mentioned management activities are supported through the use of static configurations and, dynamic additions, modifications and terminations of the connection.

Definition of the MAC Services
More communication technologies use layers structured hierarchically to divide the communication functions.Each layer performs a set of functions intended to provide some services to the higher layer.A service is a capability of a layer (service provider) that is provided to the layer above it (i.e.service user) through the service access point (SAP) (see Figure 3).A SAP is an address, which identifies the boundary between two adjacent layers.The communication between adjacent layers can be described at an abstract level through the occurrence of the service primitives (see Figure 3).The service primitives provide an abstract way to describe the interaction between the service user and the service provider.Each primitive can be a request, indication, response or confirmation.A request is issued by the service user for requesting some service from the service provider.An indication is used by the service provider to notify the service user that the other peer has invoked a request primitive or the provider itself has generated an event.A response is used by the service user to acknowledge receipt of the indication primitive from the service provider.Finally a confirmation is used by the service provider to notify the requesting service user that the activity initiated by the request has been successfully completed [12].The IEEE 802.16 standard [1] defines the service specification for the connection establishment, change and termination.It includes a set of service primitives which provide an abstract way to describe the interaction between the CS (service user) and the MAC CPS (service provider) (see Figure 4).These primitives are shown in Table 1 and described as follows: MAC_CREATE_CONNECTION (Request/Indication/Response/Confirmation): a CS entity uses this primitive to establish a connection.

MAC_TERMINATE_CONNECTION.Confirmation
The messages DSA-REQ, DSC-REQ and DSD-REQ are generated as a consequence of the occurrence of the MAC_CREATE, MAC_CHANGE, and MAC_TERMINATION service primitive requests respectively.The messages DSA-RSP, DSC-RSP and DSD-RSP are generated as a consequence of the occurrence of the MAC_CREATE, MAC_CHANGE, and MAC_TERMINATION service primitive responses respectively.The messages DSA-ACK or DSC-ACK are generated by the requesting MAC CS entity as an acknowledgement of a dynamic service addition or dynamic service change, respectively [1].They are not generated as the occurrence of any service primitive.

Sequence of Service Primitives
A service primitive sequence may include some or all of the above types of service primitives.The MAC CPS connection establishment, change and termination service primitive sequences allowed for each service user are defined and shown in Tables 2 and 3. A primitive listed in a column header may only be followed by the primitives listed in the row headers that are marked with an "X".The shaded rows indicate the sequences that can occur at the requesting side while the others represent the sequences that can occur at the requested side.These service primitive sequences were derived from IEEE 802.16 standard document [1].
A service is confirmed (confirmed service) when the service provider, which may be either the network or the requested service user, gives an explicit confirmation to the requesting service user.Thus a confirmed service primitive sequence includes all of the service primitives defined above.If a service is not confirmed (non-confirmed service), an explicit confirmation from the service provider is not required.Thus a non-confirmed service primitive sequence only includes a request and an indication.As we can see in Tables 2 and 3, all the MAC CPS connection management services are confirmed.
 Analysis: requires the proof of the desired properties of the composite specification using reachability analysis and/or theorem proving.
 Comparison: consists of checking if the service specification satisfies the service specification with the composite specification to see if the composite specification is a correct refinement of the service.
Figure 5 shows the steps involved in the protocol verification methodology.Initially, the service specification is modeled using a formal method such as CPNs [4].Then the composite specification is also modeled.Simulations can be used for initial debugging of the models.While errors are found in the simulation, the model is modified and the simulation activities repeated as shown in Figure 5.A property refers to a particular characteristic, which should be present in a protocol.For example, Holzmann [13] defines a set of general properties, which can apply to any protocol, such as no deadlocks and no livelocks.Some other particular properties, which apply to the protocol under study, can be also defined.They can be generated from the protocol specification.The desired properties of the protocol must be verified (analysis results) using formal analysis techniques such as state space analysis, system invariants, temporal logic and model checking.The analysis results may show some errors.The errors need to be analyzed in order to determine their causes.They can be a consequence of, for example, a model mistake (e.g.erroneous inscriptions), an inaccuracy of the specification or modeling assumptions.Thus, it may or may not require the model to be modified.If the model does require modification then the simulation and analysis activities must be repeated as shown in Figure 5.
A service language consists of all the possible service primitive occurrence sequences, which can occur between the (end-to-end) users of the protocol.The protocol language consists of all the possible service primitive occurrence sequences, which can be generated by the protocol entities.The resulting (service or protocol) language can be analyzed.The analysis may consist of checking that all the service primitive sequences are expected.The service and protocol language must be compared to check if they are equivalent.If some of the service primitive sequences are in the protocol language, but not in the service language or vice versa, they need to be analyzed.These sequences can be a result of, for example, a model mistake, an inaccuracy of the specification or modeling/scope assumptions.Thus, it may or may not require the model to be modified.

Service Specification of the MAC CPS Connection Management
In this work, we model and analyze the service specification of the MAC CPS connection management using the protocol verification methodology presented above.The service specification is mostly described in the IEEE 802.16 standard document [1].Since the service primitive sequences are not clearly specified in the document, we have created the Tables 2 and 3. Then we model the service specification using CPNs, with the help of the software tool CPN Tools 2.0 [15].The model is debugging using the simulation tool integrated into CPN Tools.We validate the model against some behavioral properties of the CPNs such as non-presence of deadlocks [11] [14] using the state space (also called Occurrence Graph (OG)) method.The model is described and analyzed in [11] [14].
The OG graph includes not only the transitions representing the connection management service primitives but other transitions, such as error transitions.CPN Tools [15] does not provide explicit support for language generation, which includes only the service primitive sequences.Since the OG graph can be seen as a Finite State Automaton (FSA), the service language was generated by using a well-known FSA reduction technique (Barret et al. [16]) with the aid of the FSM Tool [17].The following steps were followed for the service language generation: 1) The service primitive transitions in the CPN model are assigned different numbers (no zero).The others are marked as zero epsilon (or empty) transitions [16].The identification numbers used for the connection management service primitives are shown in table 4. 2) The OG is written to a file in a text format that can be read by the FSM tool [17] using an algorithm created for doing this and shown [3].The Terminal States, which are the dead markings and probably other markings in the OG, are generated and written to a text file.Each line of the file corresponds to a Terminal State.To simplify and make understandable OG analysis and for the correct generation of the sequence of service primitives (e.g. the language of service), it is necessary to generate the Terminal States for the FSA, which determine the completion of a sequence service primitives.Such Terminal States are determined by the occurrence of sequences service primitives shown in table 5.
3) A FSM file is generated.It is the result of concatenating the files generated in steps 2. The resulting file, which includes the FSA for the OG is converted to the binary format understood by the FSM tool (using the fsmcompile function [17]).
4) The FSA is reduced by following the algorithm described in [16].The algorithm is based on the following steps: removal of empty move cycles (remove empties), removal of empty moves (remove empties), removal of non-determinism (determinization), removal of inaccessible states (minimization), and reduction by identifying and merging equivalent states (minimization).The FSM tool provides all the programs for supporting these steps.A description of the algorithm and how the FSM tool can be used to implement it is given in [11].
5) The language accepted by the resulting minimal FSA is generated using FSM Tools [17].
Figure 6 shows the FSA that represents the occurrence of the service primitives derived from the OG.The labels on the arcs represent the ID Number which identifies the connection management service primitive as specified in table 4. Each service primitive sequence starts at node "0" (initial state), and ends in a Terminal State represented by a double circle (node "0" and "4").The sequences service primitives shown in table 6 and can be found in the FSA in the figure 6 [11] [14].
We validate the FSA by visual inspection which is possible because of the small size of the automata.Validation procedure consisted to check that all the occurrences of the service primitive sequences are correct.Also, the resulting FSA has cycles.This is expected because of the multiple setup, change and termination requests which can be initiated by an entity.

Highlights of the Service Specification
In this section, we initially describe some problems found during the modeling and analysis of the connection management service specification.Then we explain some proposals to solve the problems.In the service specification step of the protocol verification methodology, we found some information gaps and aspects that are not clearly specified in the document [11] [14].For example, the standard document does not specify the state of the interface between the requesting entity and the service provider after the service provider terminates the protocol.Moreover, we could not find the meaning of "terminate the protocol" in the document.Also, it is important that the standard document specifies the actions taken when a connection management message is received by the protocol entity.Unfortunately, some of these actions are not clearly specified in the IEEE 802.16 standard document.For example, the actions taken by the requested entity when receiving either a DSA-ACK message (i.e. an acknowledgment of a connection creation request) or a DSC-ACK message (i.e. an acknowledgment of a change connection request) sent by the requesting entity are not explained.
A connection setup, change or termination request may be rejected by the service provider.The user service (i.e. the MAC CS layer entity) should know that its request has been accepted.The standard document does not specify how this situation is reported to the requesting CS entity.
We have proposed some solutions to above questions.They were modeled and analyzed using CPNs as part of the service specification [11] [14] and are described briefly as follows:  We assume that "terminate the protocol" means that the interface between the service user and the provider returns to the state immediately prior to the generation of a rejected service request that causes the end of the protocol.
 The requested MAC should return to the state it was prior to receive an acknowledgment of a negative response to the request sent by the requesting entity (such as a DSA-REQ or DSC-REQ message).
 The requesting CS entity could be informed of a denial of its request through the occurrence of a service primitive called "Confirmation Rejected" which clearly states that the request was rejected.

Figure 1 :
Figure 1: Basic Components of the IEEE 802.16 Architecture.Base Station (BS): is a device that provides general control service, management functions and connectivity to the subscriber station and includes some entity instances of the MAC and PHY layers.

Figure 2 :
Figure 2: IEEE 802.16 Reference Model. Service Specific Convergence Sublayer (CS): the Service Data Units (SDUs) from the external networks are received through the MAC CS SAPs.Thus, the functions of the CS include the classification of external SDUs and their associations with the appropriate Service Flow (SFID) and Connection ID (CID).

Figure 3 :
Figure 3: Communication between peer entities and between CS and MAC layers CPS.
MAC_CHANGE_CONNECTION (Request/Indication/Response/Confirmation): a CS entity uses this primitive to change the characteristics of an established connection.MAC_TERMINATION_CONNECTION (Request/Indication/Response/Confirmation): a CS entity uses this primitive to terminate a connection.

Figure 4 :
Figure 4: Communication between peer entities and between CS and MAC layers CPS.

Figure 5 :
Figure 5: Abstract View of the Protocol Verification Methodology [3]

Figure 6 :
Figure 6: Minimal FSA for the connection management model

Table 1 :
Service primitives for connection management

Table 4 :
Abbreviations and ID numbers used for connection management service primitives

Table 5 :
Service Primitives sequences that define the "Terminals States"

Table 6 :
Examples of service primitive sequences accepted by the FSA