Need a document to be paraphrased and the references in IEEE format 

Secure Routing Protocols for Mobile Ad Hoc Networks

Houda Moudni1, Mohamed Er-rouidi1 1 Faculty of Sciences and Technology Sultan Moulay Slimane University

Beni Mellal, Morocco

{h.moudni, m.errouidi}

Hicham Mouncif2, Benachir El Hadadi2

2 Faculty Polydisciplinary

Sultan Moulay Slimane University Beni Mellal, Morocco

{hmouncif, benachirelhadadi}

Abstract— Mobile Ad hoc NETwork (MANET) is a collection of self-organizing mobile nodes without any help of centralized administration or established infrastructure. Due to this characteristic, MANETs are particularly vulnerable to various security threats. In addition, the design of most MANET routing protocols assumes that there is no malicious node in the network. Hence, several efforts and researches have been made toward the design of a secure and robust routing protocol for ad hoc networks. In this paper, we discuss the major attacks that can target the operation of ad hoc routing protocol. A detailed survey of the well-known secured ad hoc routing protocols for mobile ad hoc networks is presented. In order to analyze the existent solutions for securing ad hoc routing protocols in a structured manner, we have classified them into three categories: solutions based on cryptography, solutions based on one-way hash chain and hybrid solutions. This paper also gives a brief summary and comparison of various protocols available for secured routing in MANET.

Keywords—Mobile Ad hoc network; routing protocols; routing attacks; security; secure ad hoc routing protocols.


A Mobile Ad Hoc network consists of nodes that are able to communicate with each other through wireless mediums. These nodes operate not only as an end system, but also as a router to forward packets to others, without the aid of any existing infrastructure or centralized administration. Therefore, these networks have a dynamic topology since all the nodes can easily join or leave the network at any time. These features make MANET useful and practical, especially, in military and rescue areas such as connecting soldiers on the battlefield or establishing a new network to replace another which falls down after a disaster like an earthquake.

In order to provide connectivity in a mobile ad hoc network all nodes have to perform routing of network traffic. Although numerous ad hoc routing protocols have been proposed such as Destination-Sequenced Distance-Vector (DSDV) [1], Optimized Link State Routing Protocol (OLSR) [2], Dynamic Source Routing (DSR) [3] and Ad hoc On Demand Distance Vector (AODV) [4], which assumed an environment where all the nodes are perfectly cooperative and trustworthy and no security mechanism has been considered. Unfortunately, MANETs may not be such a friendly

environment due to multi-hop communication and the lack of centralized administration. Besides, malicious nodes can freely join the network and cause various performance degradation, as interfering the routing information or listen to the network communication.

To secure an ad hoc network, we consider the following attributes: availability, data confidentiality, data integrity, authentication and non-repudiation. These countermeasures considered to reduce or eliminate the security vulnerabilities and attacks in the network. In the literature, several secure ad hoc routing protocols have been proposed. In this paper, we present a detailed survey of the well-known routing protocols in terms of security and identify their limitations.

The rest of this paper is organized as follows: in Section 2, we present the possible attacks that malicious nodes can use for disrupting the operation of a routing protocol in a mobile ad hoc network. Section 3 analyzes the already proposed secure ad hoc routing protocols that exist in the literature and present their operational principles. Section 4 briefly gives a summary and comparison of the various secure routing protocols. Then, we conclude our discussion in Section 5.


Due to characteristics of mobile ad-hoc networks, MANETs are more vulnerable to be attacked than wired networks. We can distinguish two principal categories of attacks: passive and active attacks. A passive attack does not disrupt the operation of the protocol, but attempts to listen to valuable information in the traffic. Instead, an active attack disrupts the operation of the protocol in order to degrade the network performance, gain unauthorized access, and restrict availability. A brief overview of several well-known routing attacks [5, 6, 7, 8] is presented below.

a) Passive Eavesdropping Attack: The purpose of eavesdropping attack is to listen the secret or confidential routing information that should be kept secret during the communication. From the information it captures, it is able to discover potentially sensitive topology information about the network. In general, the eavesdropping is easier in mobile ad- hoc network, due to the open nature of the communication medium.

978-1-4673-7689-1/16/$31.00 ©2016 IEEE

b) Routing Data Manipulation Attack: A manipulation attack occurs when a malicious node alters the information it receives before forwarding it to the next node. Without any integrity measures the next receiving node will be unable to see any evidence of tampering, and hence, will process the incorrect information.

c) Replay Attack: A replay attack is a form of active attack in which a malicious node stores routing information and then later retransmits the stored information. This attack targets the freshness of routes, also used to undermine poorly designed security solutions.

d) Black Hole Attack: In a black hole attack, a malicious node uses the routing protocol to advertise a shortest path to a node, thus intercepting the communicating packets passing through the malicious node. As a result, instead of normally forwarding the packets that it receives, the malicious drops all packets.

e) Flooding Attack: In this attack, a malicious node aims to flood the network with a large number of RREQs in a short period to non-existent destinations in the network, and then causes severe degradation of network performance.

f) Rushing Attack: This kind of attack can be carried out against on-demand routing protocols that use duplicate suppression in their operations. Rushing node exploits this mechanism by quickly forwarding route discovery packets in order to be included in the discovered routes.

g) Tunnelling/Wormhole Attack: The Wormhole attack occurs when an attacker receives packets at one point in the network, then “tunnels” them to another point in the network; the colluding can communicate directly over long distances.

h) Sybil attack: In Sybil attack, a single node appears in the network with multiple identities. These false identities can be used to play different type of attack in the network. This attack also poses a significant threat to geographic routing protocol.

i) Denial of Service: This attack targets the availability of the node. An adversary floods an amount of data in order to consume network bandwidth or to consume the resources of a particular node. Specific instances of denial of service attacks include the overflow of the routing table and the sleep deprivation torture.


There exist several proposals that attempt to counter the security threats mentioned in the previous section, and provide protection against malicious attacks and selfish behaviors. These proposed solutions are either an integration of security mechanisms into existing protocols (e.g. AODV and OLSR), or a new stand-alone protocols. Among the security mechanisms for ad-hoc networks used nowadays, there are two techniques:

· Prevention technique: This mechanism involves protocols that prohibit the attacking node to initiate any action. These approaches usually require encryption techniques to provide authentication, integrity, etc.

Detection and Reaction: These solutions attempt to identify any malicious activities in the network and take proper action against such nodes. (e.g. Byzantine Algorithm [9], Core [10], Confidant [11], Watchdog and Pathrater [12]).

In this paper, we will focus on the prevention techniques. Therefore, to analyze the existing solutions in structured way we have classified them into three categories; solutions based on cryptography, solutions based on one-way hash chain and hybrid solutions. For the solutions based on cryptography, there are two sub-categories; solutions based on symmetric cryptography and solutions based on asymmetric cryptography.

A. Symmetric cryptography solutions

1) Secure Routing Protocol (SRP)

The Secure Routing Protocol (SRP) developed by Papadimitratos and Haas [13], is a protocol designed to secure the on-demand routing protocols that utilize broadcasting as its route querying method. The authors mentioned that can be applied as an extension of a multitude of existing reactive routing protocols, in particular the DSR [3]. A security association (SA) is required between a source node and a destination node. It is assumed that the SA can be established by using a shared key between the two communicating nodes.

A SRP Header as shown in Fig. 1 is added to the packet of the basis routing protocol. The source node initiates the route discovery, by sending a route request packet that identified by a query sequence number (QSEQ), a random query identifier (QID), and the output of a key hashed function. The key hash function takes IP header, the header of the basic routing protocol, and the shared key.












)The intermediate nodes broadcast the packet to the neighboring nodes and update their routing table. However, if they have the same QID in their routing table, the query is dropped. When the query has reached to the destination node, it verifies that the query is not outdated or replayed through the QSEQ and it checks for the security metrics by calculating of the keyed hash. After verifying, the destination node generates a number of replies with different routes, so that it provides the source with an as diverse topology picture as possible. These replies packets include the path information from source to destination, the QSEQ and QID numbers. The security metrics of the reply are ensured through the same method as the route request, by calculating the Message Authentication Code (MAC). After receiving the reply packet, source node checks the QSEQ and QID numbers, then calculates the MAC and compares the output with the MAC field of the SRP header.

SRP header

Fig. 1. SRP Packet header

According to a successful verification, source node is assured that the request is reached to the destination and that the reply was not corrupted on its way from the source to the destination.

The route error message packet is generated by an intermediate node that discovers broken links. This packet is source-routed to the source node along the prefix of the route being reported as broken. When the node receives a route error packet, it compares the route taken by the packet with the prefix of the corresponding route. However, malicious nodes can also send a route error messages. Therefore SRP provides minimal protection for route maintenance errors.

SRP can ensure proper connectivity information if a set of malicious nodes mount attacks against the protocol concurrently, but it remains weak against the wormhole attack.

2) Security aware Ad hoc Routing protocol (SAR)

The Security-aware Ad hoc Routing (SAR) protocol [14] is an approach to ad hoc routing that incorporates security attributes as parameters into route discovery. However, traditional non-secure routing protocols find out the shortest path between two nodes, while SAR can discover a path with desired security attributes. For instance, the criterion for a valid route can be when each node in the route must have a particular shared key.

SAR can be extended to any on-demand ad hoc routing protocols (such as AODV or DSR) in order to integrate the security metric into the route request messages. An implementation of SAR based on AODV is presented by the authors. The route request packet has an additional field (RQ_SEC_REQUIREMENT) that indicates the required security level of the route that she wishes to discover. This field is only set once by the sender and does not change during the route discovery. An intermediate node that receives the packet checks if it can satisfy the security requirement. If the node can provide the required security, thus it can participate in the routing and the route request packet is forwarded to its own neighbors, updating a new field called RQ_SEC_GURANTEE to indicate the maximum level of security it can provide. And if the intermediate node can’t satisfy the security requirement, it simply drops the route request packet. When the destination node receives the route request packet, it can be sure of the existence of a route from the source to the destination and this route satisfies the security requirements defined by the sender. The destination node sends a route reply packet with an additional field (RP_SEC_GUARANTEE) that indicates the maximum security available over the path. Then the value of the RQ_SEC_GURANTEE field is copied to RP_SEC_GUARANTEE. The reply packet goes back along the reverse path and the intermediate nodes that are allowed to participate in the routing, update its routing table according to the AODV specification and also record the new RP_SEC_GUARANTEE value. This value indicates the maximum security available on the cached forward path.

A major disadvantage in SAR is that it involves significant overhead to the routing process, since each intermediate node has to perform encryption/decryption operation.

Asymmetric cryptography solutions

1) Authenticated Routing for Ad hoc Networks (ARAN)

The Authenticated Routing for Ad hoc Networks (ARAN), described in [15], is a secure routing protocol based on the on- demand protocols. ARAN utilizes a cryptographic mechanism in order to achieve security goals of authentication, message integrity and non-repudiation.

It consists of two distinct operational stages; the first stage is the preliminary certification process that requires the existence of a trusted certificate authority (CA). All nodes that want to connect to the network must contact the certification authority and request a certificate for its address and public key. This certification authority distributes its public key to all the nodes in the network. The second operational stage of the protocol is the route discovery process that provided end-to- end authentication. This ensures that the intended destination was indeed reached. The initiator node starts the communication by broadcasting a route discovery packet (RDP) to its neighbors. The RDP includes a packet type identifier (“RDP”), the certificate of the initiating node, a nonce, a timestamp, and the address of the destination node, all signed with the initiating node’s private key. Every intermediate node validates the signature and verifies that the source’s certificate has not expired, updates its routing table with the neighbor from which it received the RDP, signs the contents of the message, appends its own certificate, and forwards the message to its neighbors after removing the certificate and the signature of the previous node. The signature prevents spoofing attacks that may alter routes or form loops. After receiving the RDP, the destination node replies with a reply packet (REP). The REP contains a packet type identifier (“REP”), the address of the source node, the destination’s certificate, a nonce, and the associated timestamp. Furthermore, the destination node signs the REP. Similar to the route discovery, each node removes the certificate and signature of the previous hop and replaces them with its own before forwarding it to the next hop, except that the REP is unicasted along the reverse path. When the source receives the REP, it verifies the destination’s signature and the nonce returned by the destination. Fig. 2 illustrates the process of route discovery in ARAN.

) (
)S: Source node I: Intermediate node D: Destination node 1: {RDP, nonce, timestamp, D, CertS}K -1

2: {{{RDP, nonce, timestamp, D,CertS}KS-1}KI-1,CertB} 3: {REP, nonce, timestamp, S, CertD}KD-1

)4: {{{REP, nonce, timestamp, S, CertD}KD-1}KI-1,CertB}

Fig. 2. Route discovery in the ARAN protocol

Route maintenance is realized in ARAN by ERR messages that are signed by the nodes that generate them in order to report broken links. Then, it forwarded along the reverse path toward the source without modification. Replay attacks are ensured by a nonce and a timestamp including in the ERR message. While the ERR messages are signed, malicious nodes cannot generate false broken link reports. Consequently, non- repudiation is provided. As shown in Fig. 3.

A certificate needs to be revoked when limited-time certificates is achieved. The trusted certification server broadcasts a revocation message to the network. All receiving nodes re-broadcasts this message it to its neighbors. The authors mentioned that this method is not failsafe, since a revocation message might not be propagated by the malicious node creating a partition in the network.

The ARAN protocol provides both node-to-node and end- to-end authentication, that guarantee a protection from modification, impersonation, and fabrication attacks. However, due to heavy asymmetric cryptographic operations and large routing packets, ARAN suffers from a higher overall routing load and higher latency in route discovery.

C. Prevention using One-Way Hash Chains

1) Secure Efficient Ad hoc Distance vector (SEAD)

The Secure Efficient Ad hoc Distance vector (SEAD) [16] is a secure ad hoc network routing protocol based on the design of the DSDV [1] routing protocol, in particular, on the DSDV- SQ version of this protocol. SEAD uses a hash chain to authenticate hop counts and sequence numbers and does not involve any asymmetric cryptographic operations.

In SEAD, each node creates its hash chain by applying a one-way hash function to a random value. Furthermore, particular elements from the hash chain are used to secure the updates of the routing protocol. However, the protocol is based on the assumption of the existence of a certain mechanism in order to authenticate one element of a hash chain between two nodes. Hence, when a node sends or transmits a routing update, it includes one value from the hash chain for each entry in that update. In a way that a node includes the address of the destination node, the metric and the sequence number of the destination from its routing table, and the hash value to the hash of the hash value received in the routing update entry from which it learned that route to that destination. If the update concerns itself, the node includes its own address, it sets the metric to 0 and the sequence number to the next sequence number, and the hash value to the first element in its own hash chain corresponding to that sequence number. Nodes receiving a routing update check the authentication of each entry of the message, by hashing the hash value received of each entry the correct number of times and it is compared to the prior authentic hash value. According to this comparison the routing update is either accepted as authenticated or discarded. Using this technique, other nodes can only increase the metric in a routing update, but not to decrease it.

SEAD is robust against multiple uncoordinated attackers trying to create an incorrect routing state in any other node, even in spite of compromised nodes or active attackers.

S: Source node I1 & I2: Intermediate node D: Destination node


2 1: {ERR, nonce, timestamp, S, D, CertI2}KI2-1 2: {ERR, nonce, timestamp, S, D, CertI2}KI2-1






Fig. 3. Route maintenance in the ARAN protocol

Additionally, SEAD proposes two different methods to authenticate the source of each routing update message in order to avoid the creation of routing loops. The first one requires clock synchronization between the nodes that participate in the ad hoc network, and employs broadcast authentication mechanisms such as TESLA [17], HORS [18] or TIK [19]. The second method assumes a shared secret key among each pair of nodes in order to use a message authentication code (MAC) between the nodes for the authentication of a routing update message.

The routing protocol SEAD provides strong protection against attackers trying to create incorrect routing state, but fails against the wormhole attack.

2) Ariadne

Ariadne [20] is a secure reactive ad hoc routing protocol based on the DSR [3]; this protocol is developed by the same authors in the SEAD protocol described above. Instead of employing the hop by hop security mechanisms as in the protocol SEAD, the proposal Ariadne follows an end-to-end approach.

The design of Ariadne can be viewed as having three stages: Authentication of ROUTE REQUEST by target, techniques for authenticating data in ROUTE REQUEST and ROUTE REPLY, and Per-hop hashing technique.

· Authentication of ROUTE REQUESTs by target: this stage consists to verify the authenticity of the ROUTE REQUEST, that it is filled when the initiator node includes a MAC computed with a shared key over unique data, for example a timestamp, in the ROUTE REQUEST.

· Techniques for authenticating data in ROUTE REQUEST and ROUTE REPLY: this stage allows the initiator node to authenticate each individual node in the node list of the ROUTE REPLY. Also the target node can authenticate each node in the node list of the ROUTE REQUEST, in order to ROUTE REPLY will return only along the paths that contain legitimate nodes. According to the authors, authentication can be performed by using one of three schemes: shared secrets between each pair of nodes, shared secrets between communicating nodes

combined with the TESLA [17] broadcast authentication protocol which requires loose time synchronization, or a digital signature.

· Per-hop hashing technique: A one-way hash function is used to verify that no node was removed from the node list in the ROUTE REQUEST. To change or remove a previous hop, an attacker must be able to invert the one- way hash function, which has been proved computationally impracticable.

Ariadne provides a good defense against attackers or compromised nodes from tampering with uncompromised routes consisting of uncompromised nodes, it also prevents many types of Denial-of-Service attacks. Additionally, Ariadne relies only on highly efficient symmetric cryptography.

Ariadne is a robust protocol based on DSR, it provides end-to-end security mechanisms for ad hoc routing protocol. The most important requirement of Ariadne with TESLA is the existence of clock synchronization in the ad hoc network. However, the basic Ariadne protocol can be affected by a wormhole and rushing attacks.

D. Hybrid solutions

1) Secure Ad hoc On-demand Distance Vector protocol (SAODV)

The Secure Ad hoc On-demand Distance Vector protocol (SAODV) is an extension to AODV routing protocol [21]. The proposed extensions utilize cryptographic signatures for authenticating the non-mutable fields of the messages, and one way hash chain for secure the hop-count field within the RREQ and RREP messages, which is the only mutable field of an AODV message. The protocol requires the existence of a key management mechanism that allows for every node to obtain public keys from the other nodes that participate in the ad hoc network.

The information relative to the signatures and the hash chains is transmitted with the AODV message as an extension message that the authors refer to as Signature Extension. These SAODV extensions consist of the following fields. The hash function field indicates which hash function has to be used. The field max hop count specifies the maximum number of nodes a packet is allowed to go through. The field hash is a randomly generated number called as seed. Finally, the top hash field is calculated by hashing the value in the Hash field Max Hop Count times. The format of the SAODV signature extensions is shown in Fig. 4.



Hash function

Max Hop Count

Top Hash



Fig. 4. SAODV protocol header

Every time a node originates a route request or a route reply AODV packet generates a random number (seed) and sets the hash field to the seed value, sets the max hop count field to the time to live (TTL) field from the IP header, specifies the hash function field by the identifier of the hash function that it is going to use, and applies the hash function to the seed max hop count times, the calculated result sets to the top hash field. Furthermore, the node digitally signs all fields of the message, except the hop count field from the AODV header and the hash field from the SAODV extension header. After receiving a route request or a route reply, the intermediate node verifies the hop count AODV field by comparing the result of the hashing max hop count minus hop count times to the hash field with the value of the top hash field. If the check fails, the packet will be dropped by the node. The intermediate node hashes one time the old value of the Hash field in the Signature Extension, before rebroadcasting a RREQ message to its neighbors or forwarding a RREP.

The authors mentioned that the main problem in applying digital signatures is that AODV allows intermediate nodes to reply RREQ messages if they have a fresh route to the destination. For solving this problem, the authors suggest two solutions. The first one is to forward the RREQ message since intermediate nodes cannot sign its RREP message. The second solution consists of using the double signature extension described in [21] to reply to a route request.

For the broken links an error message (RERR) is generated by the nodes. Every node that generates or forwards a route error message use digital signatures to sign the whole message, except the destination sequence numbers. And any neighbor that receives it verifies the signature.

The security features provided by SAODV include integrity, authentication and non-repudiation. Nevertheless, due to the use of asymmetric cryptography, SAODV suffers from degradation of the performance. In addition, SAODV is affected by the Wormhole attack. And a hop count authentication by using hash chains is not perfect while a malicious node might forward a message without increase the hop count.

2) Secure Link State Routing Protocol (SLSP)

The Secure Link State Routing Protocol (SLSP) [22] is a proposed scheme for securing proactive routing for mobile ad hoc networks and the distribution of link state information for locals and network-wide scoped topologies. SLSP can be used as either as a stand-alone solution for proactive link-state routing, or as a part of the hybrid routing framework when combined with a reactive ad hoc routing protocol. However, The SLSP requires the existence of an asymmetric key pair for every network interface of a node.

There are three major steps in SLSP: public key distribution, neighbor discovery, and link state updates.

· Public key distribution: To function efficiently without central key management, each node broadcasts its public key to nodes within its zone using signed public key distribution (PKD) packets. Then

receiving nodes validate their subsequent link state updates from the source node.

· Neighbor discovery: Link state information of the node is also broadcast periodically using the Neighbor Lookup Protocol (NLP), an internal part of SLSP. Every node sends its MAC address and IP address of the current network interface, to its neighbors by broadcasting signed NLP hello messages. A node’s NLP generates a notification to inform SLSP when suspicious discrepancies are observed, such as two neighbors used the same IP address, or a node uses the same MAC address as the detecting node, etc. While receiving the notification, the routing protocol discards immediately the suspicious packets.

· Link state updates: Link state update (LSU) packets are identified by the IP address of the initiating node and include a 32-bit sequence number, which provides an ample space of updates. Each update includes a hop count representing the number of hops traveled by the SLSP updates. A hash chain is used to authenticate the hop count, and the hash chain values are performed through the hash chain’s anchor, which is included in the digitally signed part of an LSU message. Upon the reception of the LSU, the nodes check the attached signature using a public key of the originating node. The hops_traversed field of the LSU is set to hashed hops_traversed, the TTL is decremented, and the packet is rebroadcast.

SLSP is robust against denial of service attacks, while every node maintains a priority ranking of their neighboring nodes according to the rate of control traffic they have observed. Neighbor nodes that generate update packets with the highest rate are given lowest priorities and vice versa.

The routing protocol SLSP provides secure proactive topology discovery for mobile ad hoc networks. The protocol guarantees a protection from individual malicious nodes. However, it remains vulnerable to colluding attackers that fabricate non-existing links between themselves and flood this information to their neighbors.



In this section, a comparative summary of the previously presented secure ad hoc routing protocols is given below in Table 1. We concluded that there is no single routing protocol that provides protection against all forms of routing attacks. In addition, the achievable security level is highly dependent on both the assumptions and operational requirements.


In this paper, we have presented the most known protocols for securing the routing function in mobile ad hoc networks. The analysis of the various proposed routing protocols has demonstrated that the inherent characteristics of ad hoc networks, such as rapidly changing topologies and lack of infrastructure, introduce further difficulties to the already complicated problem of secure routing. Our study shows that, none of the proposals of secure routing protocols are able to accomplish all security goals. In addition, security overhead comes mainly from the computational complexity of the cryptographic algorithms used in constantly repeated routing procedures. In future work, we will propose improvements in AODV routing protocol for secure network layer communication in MANETs.


[1] Perkins, C. E., & Bhagwat, P. (1994, October). Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers. In ACM SIGCOMM computer communication review (Vol. 24, No. 4, pp. 234-244). ACM.

[2] Clausen, T., & Jacquet, P. (2003). Optimized link state routing protocol (OLSR)(No. RFC 3626).

[3] Johnson, D. B., & Maltz, D. A. (1996). Dynamic source routing in ad hoc wireless networks. In Mobile computing (pp. 153-181). Springer US.

[4] Perkins, C., Belding-Royer, E., & Das, S. (2003). Ad hoc on-demand distance vector (AODV) routing (No. RFC 3561).

[5] Kapur, R. K., & Khatri, S. K. (2015, March). Analysis of attacks on routing protocols in MANETs. In Computer Engineering and Applications (ICACEA), 2015 International Conference on Advances in (pp. 791-798). IEEE.


Secured Routing Protocol








Secure From:

























Worm hole attack








Selfish nodes








[6] Rajakumar, P., Prasanna, V. T., & Pitchaikkannu, A. (2014, February). Security attacks and detection schemes in MANET. In Electronics and Communication Systems (ICECS), 2014 International Conference on (pp. 1-6). IEEE.

[7] Khan, M. S., Jadoon, Q. K., & Khan, M. I. (2015). A Comparative Performance Analysis of MANET Routing Protocols under Security Attacks. In Mobile and Wireless Technology 2015 (pp. 137-145). Springer Berlin Heidelberg.

[8] Saeed, A., Raza, A., & Abbas, H. (2014, June). A Survey on Network Layer Attacks and AODV Defense in Mobile Ad Hoc Networks. In Software Security and Reliability-Companion (SERE-C), 2014 IEEE Eighth International Conference on (pp. 185-191). IEEE.

[9] Awerbuch, B., Holmer, D., Nita-Rotaru, C., & Rubens, H. (2002, September). An on-demand secure routing protocol resilient to byzantine failures. InProceedings of the 1st ACM workshop on Wireless security (pp. 21-30). ACM.

[10] Michiardi, P., & Molva, R. (2002). Core: a collaborative reputation mechanism to enforce node cooperation in mobile ad hoc networks. In Advanced Communications and Multimedia Security (pp. 107- 121). Springer US.

[11] Buchegger, S., & Le Boudec, J. Y. (2002, June). Performance analysis of the CONFIDANT protocol. In Proceedings of the 3rd ACM international symposium on Mobile ad hoc networking & computing (pp. 226-236). ACM.

[12] Marti, S., Giuli, T. J., Lai, K., & Baker, M. (2000, August). Mitigating routing misbehavior in mobile ad hoc networks. In Proceedings of the 6th annual international conference on Mobile computing and networking (pp. 255-265). ACM.

[13] Papadimitratos, P., & Haas, Z. J. (2002). Secure routing for mobile ad hoc networks. In the SCS Commnication Networks and Distributed Systems Modeling and Simulation Conference (CNDS), San Antonio, TX, January 27-31, 2002 (pp. 193-204).

Yi, S., Naldurg, P., & Kravets, R. (2001, October). Security-aware ad hoc routing for wireless networks. In Proceedings of the 2nd ACM international symposium on Mobile ad hoc networking & computing (pp. 299-302). ACM.

[15] Sanzgiri, K., Dahill, B., Levine, B. N., Shields, C., & Royer, E. M. B. (2002, November). A secure routing protocol for ad hoc networks. In Network Protocols, 2002. Proceedings. 10th IEEE International Conference on (pp. 78-87). IEEE.

[16] Hu, Y. C., Johnson, D. B., & Perrig, A. (2003). SEAD: Secure efficient distance vector routing for mobile wireless ad hoc networks. Ad hoc networks,1(1), 175-192.

[17] Perrig, A., Canetti, R., Song, D., & Tygar, J. D. (2001, February). Efficient and secure source authentication for multicast. In Network and Distributed System Security Symposium, NDSS (Vol. 1, pp. 35- 46).

[18] Reyzin, L., & Reyzin, N. (2002, July). Better than BiBa: Short one- time signatures with fast signing and verifying. In Information Security and Privacy(pp. 144-153). Springer Berlin Heidelberg.

[19] Perrig, A., Hu, Y. C., & Johnson, D. B. (2001, December). Wormhole protection in wireless ad hoc networks. In Proceedings of the Eighth Annual International Conference on Mobile Computing and Networking.

[20] Hu, Y. C., Perrig, A., & Johnson, D. B. (2005). Ariadne: A secure on- demand routing protocol for ad hoc networks. Wireless networks, 11(1-2), 21-38.

[21] Zapata, M. G., & Asokan, N. (2002, September). Securing ad hoc routing protocols. In Proceedings of the 1st ACM workshop on Wireless security (pp. 1-10). ACM.

[22] Papadimitratos, P., & Haas, Z. J. (2003, January). Secure link state routing for mobile ad hoc networks. In Applications and the Internet Workshops, 2003. Proceedings. 2003 Symposium on (pp. 379-383). IEEE.

[footnoteRef:1] [1: This paragraph of the first footnote will contain the date on which you submitted your paper for review. It will also contain support information, including sponsor and financial support acknowledgment. For example, “This work was supported in part by the U.S. Department of Commerce under Grant BS123456”.
The next few paragraphs should contain the authors’ current affiliations, including current address and e-mail. For example, F. A. Author is with the National Institute of Standards and Technology, Boulder, CO 80305 USA (e-mail: [email protected]
S. B. Author, Jr., was with Rice University, Houston, TX 77005 USA. He is now with the Department of Physics, Colorado State University, Fort Collins, CO 80523 USA (e-mail: [email protected]).
T. C. Author is with the Electrical Engineering Department, University of Colorado, Boulder, CO 80309 USA, on leave from the National Research Institute for Metals, Tsukuba, Japan (e-mail: [email protected]).]

Preparation of Papers for IEEE TRANSACTIONS and JOURNALS (December 2013)

First A. Author, Fellow, IEEE, Second B. Author, and Third C. Author, Jr., Member, IEEE

Abstract—These instructions give you guidelines for preparing papers for IEEE Transactions and Journals. Use this document as a template if you are using Microsoft Word 6.0 or later. Otherwise, use this document as an instruction set. The electronic file of your paper will be formatted further at IEEE. Paper titles should be written in uppercase and lowercase letters, not all uppercase. Avoid writing long formulas with subscripts in the title; short formulas that identify the elements are fine (e.g., “Nd–Fe–B”). Do not write “(Invited)” in the title. Full names of authors are preferred in the author field, but are not required. Put a space between authors’ initials. Define all symbols used in the abstract. Do not cite references in the abstract. Do not delete the blank line immediately above the abstract; it sets the footnote at the bottom of this column.

Index Terms—Enter key words or phrases in alphabetical order, separated by commas. For a list of suggested keywords, send a blank e-mail to
[email protected] or visit



HIS document is a template for Microsoft Word versions 6.0 or later. If you are reading a paper or PDF version of this document, please download the electronic file,
TRANS-JOUR.DOC, from the IEEE Web site at so you can use it to prepare your manuscript. If you would prefer to use LATEX, download IEEE’s LATEX style and sample files from the same Web page. Use these LATEX files for formatting, but please follow the instructions in TRANS-JOUR.DOC or TRANS-JOUR.PDF.

If your paper is intended for a conference, please contact your conference editor concerning acceptable word processor formats for your particular conference.

Guidelines For Manuscript Preparation

When you open TRANS-JOUR.DOC, select “Page Layout” from the “View” menu in the menu bar (View | Page Layout), (these instructions assume MS 6.0. Some versions may have alternate ways to access the same functionalities noted here). Then, type over sections of TRANS-JOUR.DOC or cut and paste from another document and use markup styles. The pull-down style menu is at the left of the Formatting Toolbar at the top of your Word window (for example, the style at this point in the document is “Text”). Highlight a section that you want to designate with a certain style, then select the appropriate name on the style menu. The style will adjust your fonts and line spacing. Do not change the font sizes or line spacing to squeeze more text into a limited number of pages. Use italics for emphasis; do not underline.

To insert images in Word, position the cursor at the insertion point and either use Insert | Picture | From File or copy the image to the Windows clipboard and then Edit | Paste Special | Picture (with “float over text” unchecked).

IEEE will do the final formatting of your paper. If your paper is intended for a conference, please observe the conference page limits.

Abbreviations and Acronyms

Define abbreviations and acronyms the first time they are used in the text, even after they have already been defined in the abstract. Abbreviations such as IEEE, SI, ac, and dc do not have to be defined. Abbreviations that incorporate periods should not have spaces: write “C.N.R.S.,” not “C. N. R. S.” Do not use abbreviations in the title unless they are unavoidable (for example, “IEEE” in the title of this article).

Other Recommendations

Use one space after periods and colons. Hyphenate complex modifiers: “zero-field-cooled magnetization.” Avoid dangling participles, such as, “Using (1), the potential was calculated.” [It is not clear who or what used (1).] Write instead, “The potential was calculated by using (1),” or “Using (1), we calculated the potential.”

Use a zero before decimal points: “0.25,” not “.25.” Use “cm3,” not “cc.” Indicate sample dimensions as “0.1 cm 0.2 cm,” not “0.1 0.2 cm2.” The abbreviation for “seconds” is “s,” not “sec.” Use “Wb/m2” or “webers per square meter,” not “webers/m2.” When expressing a range of values, write “7 to 9” or “7-9,” not “7~9.”

A parenthetical statement at the end of a sentence is punctuated outside of the closing parenthesis (like this). (A parenthetical sentence is punctuated within the parentheses.) In American English, periods and commas are within quotation marks, like “this period.” Other punctuation is “outside”! Avoid contractions; for example, write “do not” instead of “don’t.” The serial comma is preferred: “A, B, and C” instead of “A, B and C.”

If you wish, you may write in the first person singular or plural and use the active voice (“I observed that …” or “We observed that …” instead of “It was observed that …”). Remember to check spelling. If your native language is not English, please get a native English-speaking colleague to carefully proofread your paper.

How to Create a PostScript File

First, download a PostScript printer driver from (for Windows) or from pdrvmac.htm (for Macintosh) and install the “Generic PostScript Printer” definition. In Word, paste your figure into a new document. Print to a file using the PostScript printer driver. File names should be of the form “” Use Open Type fonts when creating your figures, if possible. A listing of the acceptable fonts are as follows: Open Type Fonts: Times Roman, Helvetica, Helvetica Narrow, Courier, Symbol, Palatino, Avant Garde, Bookman, Zapf Chancery, Zapf Dingbats, and New Century Schoolbook.


If you are using Word, use either the Microsoft Equation Editor or the MathType add-on ( for equations in your paper (Insert | Object | Create New | Microsoft Equation or MathType Equation). “Float over text” should not be selected.


Number equations consecutively with equation numbers in parentheses flush with the right margin, as in (1). First use the equation editor to create the equation. Then select the “Equation” markup style. Press the tab key and write the equation number in parentheses. To make your equations more compact, you may use the solidus ( / ), the exp function, or appropriate exponents. Use parentheses to avoid ambiguities in denominators. Punctuate equations when they are part of a sentence, as in


Be sure that the symbols in your equation have been defined before the equation appears or immediately following. Italicize symbols (T might refer to temperature, but T is the unit tesla). Refer to “(1),” not “Eq. (1)” or “equation (1),” except at the beginning of a sentence: “Equation (1) is … .”


Use either SI (MKS) or CGS as primary units. (SI units are strongly encouraged.) English units may be used as secondary units (in parentheses). This applies to papers in data storage. For example, write “15 Gb/cm2 (100 Gb/in2).” An exception is when English units are used as identifiers in trade, such as “3½-in disk drive.” Avoid combining SI and CGS units, such as current in amperes and magnetic field in oersteds. This often leads to confusion because equations do not balance dimensionally. If you must use mixed units, clearly state the units for each quantity in an equation.

The SI unit for magnetic field strength H is A/m. However, if you wish to use units of T, either refer to magnetic flux density B or magnetic field strength symbolized as µ0H. Use the center dot to separate compound units, e.g., “A·m2.”

Some Common Mistakes

The word “data” is plural, not singular. The subscript for the permeability of vacuum µ0 is zero, not a lowercase letter “o.” The term for residual magnetization is “remanence”; the adjective is “remanent”; do not write “remnance” or “remnant.” Use the word “micrometer” instead of “micron.” A graph within a graph is an “inset,” not an “insert.” The word “alternatively” is preferred to the word “alternately” (unless you really mean something that alternates). Use the word “whereas” instead of “while” (unless you are referring to simultaneous events). Do not use the word “essentially” to mean “approximately” or “effectively.” Do not use the word “issue” as a euphemism for “problem.” When compositions are not specified, separate chemical symbols by en-dashes; for example, “NiMn” indicates the intermetallic compound Ni0.5Mn0.5 whereas “Ni–Mn” indicates an alloy of some composition NixMn1-x.

Be aware of the different meanings of the homophones “affect” (usually a verb) and “effect” (usually a noun), “complement” and “compliment,” “discreet” and “discrete,” “principal” (e.g., “principal investigator”) and “principle” (e.g., “principle of measurement”). Do not confuse “imply” and “infer.”

Prefixes such as “non,” “sub,” “micro,” “multi,” and “ultra” are not independent words; they should be joined to the words they modify, usually without a hyphen. There is no period after the “et” in the Latin abbreviation “et al.” (it is also italicized). The abbreviation “i.e.,” means “that is,” and the abbreviation “e.g.,” means “for example” (these abbreviations are not italicized).

A general IEEE styleguide is available at

Fig. 1. Magnetization as a function of applied field. Note that “Fig.” is abbreviated. There is a period after the figure number, followed by two spaces. It is good practice to explain the significance of the figure in the caption.


Units for Magnetic Properties



Conversion from Gaussian and


magnetic flux

1 Mx 108 Wb = 108 V·s


magnetic flux density,

magnetic induction

1 G 104 T = 104 Wb/m2


magnetic field strength

1 Oe 103/(4) A/m


magnetic moment

1 erg/G = 1 emu

103 A·m2 = 103 J/T



1 erg/(G·cm3) = 1 emu/cm3

103 A/m



1 G 103/(4) A/m

specific magnetization

1 erg/(G·g) = 1 emu/g 1 A·m2/kg


magnetic dipole


1 erg/G = 1 emu

4 1010 Wb·m


magnetic polarization

1 erg/(G·cm3) = 1 emu/cm3

4 104 T



1 4

mass susceptibility

1 cm3/g 4 103 m3/kg


1 4 107 H/m

= 4 107 Wb/(A·m)


relative permeability


w, W

energy density

1 erg/cm3 101 J/m3

N, D

demagnetizing factor

1 1/(4)

Vertical lines are optional in tables. Statements that serve as captions for the entire table do not need footnote letters.

aGaussian units are the same as cg emu for magnetostatics; Mx = maxwell, G = gauss, Oe = oersted; Wb = weber, V = volt, s = second, T = tesla, m = meter, A = ampere, J = joule, kg = kilogram, H = henry.

Guidelines for Graphics Preparation
and Submission

Types of Graphics

The following list outlines the different types of graphics published in IEEE journals. They are categorized based on their construction, and use of color / shades of gray:

Color/Grayscale figures

Figures that are meant to appear in color, or shades of black/gray. Such figures may include photographs,
illustrations, multicolor graphs, and flowcharts.

Lineart figures

Figures that are composed of only black lines and shapes. These figures should have no shades or half-tones of gray. Only black and white.

Author photos

Head and shoulders shots of authors which appear at the end of our papers.

Data charts which are typically black and white, but sometimes include color.

Multipart figures

Figures compiled of more than one sub-figure presented side-by-side, or stacked. If a multipart figure is made up of multiple figure types (one part is lineart, and another is grayscale or color) the figure should meet the stricter guidelines.

File Formats For Graphics

Format and save your graphics using a suitable graphics processing program that will allow you to create the images as PostScript (PS), Encapsulated PostScript (.EPS), Tagged Image File Format (.TIFF), Portable Document Format (.PDF), or Portable Network Graphics (.PNG) sizes them, and adjusts the resolution settings. If you created your source files in one of the following programs you will be able to submit the graphics without converting to a PS, EPS, TIFF, PDF, or PNG file: Microsoft Word, Microsoft PowerPoint, or Microsoft Excel. Though it is not required, it is recommended that these files be saved in PDF format rather than DOC, XLS, or PPT. Doing so will protect your figures from common font and arrow stroke issues that occur when working on the files across multiple platforms. When submitting your final paper, your graphics should all be submitted individually in one of these formats along with the manuscript.

Sizing of Graphics

Most charts, graphs, and tables are one column wide (3.5 inches / 88 millimeters / 21 picas) or page wide (7.16 inches / 181 millimeters / 43 picas). The maximum depth a graphic can be is 8.5 inches (216 millimeters / 54 picas). When choosing the depth of a graphic, please allow space for a caption. Figures can be sized between column and page widths if the author chooses, however it is recommended that figures are not sized less than column width unless when necessary.

There is currently one publication with column measurements that don’t coincide with those listed above. Proceedings of the IEEE has a column measurement of 3.25 inches (82.5 millimeters / 19.5 picas).

The final printed size of author photographs is exactly
1 inch wide by 1.25 inches tall (25.4 millimeters x 31.75 millimeters / 6 picas x 7.5 picas). Author photos printed in editorials measure 1.59 inches wide by 2 inches tall (40 millimeters x 50 millimeters / 9.5 picas x 12 picas).


The proper resolution of your figures will depend on the type of figure it is as defined in the “Types of Figures” section. Author photographs, color, and grayscale figures should be at least 300dpi. Lineart, including tables should be a minimum of 600dpi.

Vector Art

While IEEE does accept, and even recommends that authors submit artwork in vector format, it is our policy is to rasterize all figures for publication. This is done in order to preserve the figures’ integrity across multiple computer platforms.

Color Space

The term color space refers to the entire sum of colors that can be represented within the said medium. For our purposes, the three main color spaces are Grayscale, RGB (red/green/blue) and CMYK (cyan/magenta/yellow/black). RGB is generally used with on-screen graphics, whereas CMYK is used for printing purposes.

All color figures should be generated in RGB or CMYK color space. Grayscale images should be submitted in Grayscale color space. Line art may be provided in grayscale OR bitmap colorspace. Note that “bitmap colorspace” and “bitmap file format” are not the same thing. When bitmap color space is selected, .TIF/.TIFF is the recommended file format.

Accepted Fonts Within Figures

When preparing your graphics IEEE suggests that you use of one of the following Open Type fonts: Times New Roman, Helvetica, Arial, Cambria, and Symbol. If you are supplying EPS, PS, or PDF files all fonts must be embedded. Some fonts may only be native to your operating system; without the fonts embedded, parts of the graphic may be distorted or missing.

A safe option when finalizing your figures is to strip out the fonts before you save the files, creating “outline” type. This converts fonts to artwork what will appear uniformly on any screen.

Using Labels Within Figures

Figure Axis labels

Figure axis labels are often a source of confusion. Use words rather than symbols. As an example, write the quantity “Magnetization,” or “Magnetization M,” not just “M.” Put units in parentheses. Do not label axes only with units. As in Fig. 1, for example, write “Magnetization (A/m)” or “Magnetization (Am1),” not just “A/m.” Do not label axes with a ratio of quantities and units. For example, write “Temperature (K),” not “Temperature/K.”

Multipliers can be especially confusing. Write “Magnetization (kA/m)” or “Magnetization (103 A/m).” Do not write “Magnetization (A/m) 1000” because the reader would not know whether the top axis label in Fig. 1 meant 16000 A/m or 0.016 A/m. Figure labels should be legible, approximately 8 to 10 point type.

Subfigure Labels in Multipart Figures and Tables

Multipart figures should be combined and labeled before final submission. Labels should appear centered below each subfigure in 8 point Times New Roman font in the format of (a) (b) (c).

File Naming

Figures (line artwork or photographs) should be named starting with the first 5 letters of the author’s last name. The next characters in the filename should be the number that represents the sequential location of this image in your article. For example, in author “Anderson’s” paper, the first three figures would be named ander1.tif, ander2.tif, and

Tables should contain only the body of the table (not the caption) and should be named similarly to figures, except that ‘.t’ is inserted in-between the author’s name and the table number. For example, author Anderson’s first three tables would be named ander.t1.tif,, ander.t3.eps.

Author photographs should be named using the first five characters of the pictured author’s last name. For example, four author photographs for a paper may be named:, moshc.tif, chen.eps, and duran.pdf.

If two authors or more have the same last name, their first initial(s) can be substituted for the fifth, fourth, third… letters of their surname until the degree where there is differentiation. For example, two authors Michael and Monica Oppenheimer’s photos would be named oppmi.tif, and oppmo.eps.

Referencing a Figure or Table Within Your Paper

When referencing your figures and tables within your paper, use the abbreviation “Fig.” even at the beginning of a sentence. Do not abbreviate “Table.” Tables should be numbered with Roman Numerals.

Checking Your Figures: The IEEE Graphics Checker

The IEEE Graphics Checker Tool enables authors to pre-screen their graphics for compliance with IEEE Transactions and Journals standards before submission. The online tool, located at, allows authors to upload their graphics in order to check that each file is the correct file format, resolution, size and colorspace; that no fonts are missing or corrupt; that figures are not compiled in layers or have transparency, and that they are named according to the IEEE Transactions and Journals naming convention. At the end of this automated process, authors are provided with a detailed report on each graphic within the web applet, as well as by email.

For more information on using the Graphics Checker Tool
or any other graphics related topic, contact the IEEE Graphics Help Desk by e-mail at [email protected].

Submitting Your Graphics

Because IEEE will do the final formatting of your paper,
you do not need to position figures and tables at the top and bottom of each column. In fact, all figures, figure captions, and tables can be placed at the end of your paper. In addition to, or even in lieu of submitting figures within your final manuscript, figures should be submitted individually, separate from the manuscript in one of the file formats listed above in section VI-J. Place figure captions below the figures; place table titles above the tables. Please do not include captions as part of the figures, or put them in “text boxes” linked to the figures. Also, do not place borders around the outside of your figures.

Color Processing / Printing in IEEE Journals

All IEEE Transactions, Journals, and Letters allow an author to publish color figures on IEEE Xplore® at no charge, and automatically convert them to grayscale for print versions. In most journals, figures and tables may alternatively be printed in color if an author chooses to do so. Please note that this service comes at an extra expense to the author. If you intend to have print color graphics, include a note with your final paper indicating which figures or tables you would like to be handled that way, and stating that you are willing to pay the additional fee.


A conclusion section is not required. Although a conclusion may review the main points of the paper, do not replicate the abstract as the conclusion. A conclusion might elaborate on the importance of the work or suggest applications and extensions.


Appendixes, if needed, appear before the acknowledgment.


The preferred spelling of the word “acknowledgment” in American English is without an “e” after the “g.” Use the singular heading even if you have many acknowledgments. Avoid expressions such as “One of us (S.B.A.) would like to thank … .” Instead, write “F. A. Author thanks … .” In most cases, sponsor and financial support acknowledgments are placed in the unnumbered footnote on the first page, not here.

References and Footnotes

A. References

References need not be cited in text. When they are, number citations on the line, in square brackets inside the punctuation. Multiple references are each numbered with separate brackets. When citing a section in a book, please give the relevant page numbers. In text, refer simply to the reference number. Do not use “Ref.” or “reference” except at the beginning of a sentence: “Reference [3] shows … .” Please do not use automatic endnotes in Word, rather, type the reference list at the end of the paper using the “References” style.

Reference numbers are set flush left and form a column of their own, hanging out beyond the body of the reference. The reference numbers are on the line, enclosed in square brackets. In all references, the given name of the author or editor is abbreviated to the initial only and precedes the last name. Use them all; use et al. only if names are not given. Use commas around Jr., Sr., and III in names. Abbreviate conference titles. When citing IEEE transactions, provide the issue number, page range, volume number, year, and/or month if available. When referencing a patent, provide the day and the month of issue, or application. References may not include all information; please obtain and include relevant information. Do not combine references. There must be only one reference with each number. If there is a URL included with the print reference, it can be included at the end of the reference.

Other than books, capitalize only the first word in a paper title, except for proper nouns and element symbols. For papers published in translation journals, please give the English citation first, followed by the original foreign-language citation See the end of this document for formats and examples of common references. For a complete discussion of references and their formats, see “The IEEE Style Manual,” available as a PDF link off the
Author Digital Toolbox
main page.


Number footnotes separately in superscripts (Insert | Footnote).[footnoteRef:2] Place the actual footnote at the bottom of the column in which it is cited; do not put footnotes in the reference list (endnotes). Use letters for table footnotes (see Table I). [2: It is recommended that footnotes be avoided (except for the unnumbered footnote with the receipt date on the first page). Instead, try to integrate the footnote information into the text.]

Submitting Your Paper for Review

Review Stage Using Word 6.0 or Higher

If you want to submit your file with one column electronically, please do the following:

–First, click on the View menu and choose Print Layout.

–Second, place your cursor in the first paragraph. Go to the Format menu, choose Columns, choose one column Layout, and choose “apply to whole document” from the dropdown menu.

–Third, click and drag the right margin bar to just over 4 inches in width.

The graphics will stay in the “second” column, but you can drag them to the first column. Make the graphic wider to push out any text that may try to fill in next to the graphic.

Final Stage Using Word 6.0

When you submit your final version (after your paper has been accepted), print it in two-column format, including figures and tables. You must also send your final manuscript on a disk, via e-mail, or through a Web manuscript submission system as directed by the society contact. You may use Zip for large files, or compress files using Compress, Pkzip, Stuffit, or Gzip.

Also, send a sheet of paper or PDF with complete contact information for all authors. Include full mailing addresses, telephone numbers, fax numbers, and e-mail addresses. This information will be used to send each author a complimentary copy of the journal in which the paper appears. In addition, designate one author as the “corresponding author.” This is the author to whom proofs of the paper will be sent. Proofs are sent to the corresponding author only.

Review Stage Using ScholarOne® Manuscripts

Contributions to the Transactions, Journals, and Letters may be submitted electronically on IEEE’s on-line manuscript submission and peer-review system, ScholarOne® Manuscripts. You can get a listing of the publications that participate in ScholarOne at First check if you have an existing account. If there is none, please create a new account. After logging in, go to your Author Center and click “Submit First Draft of a New Manuscript.”

Along with other information, you will be asked to select the subject from a pull-down list. Depending on the journal, there are various steps to the submission process; you must complete all steps for a complete submission. At the end of each step you must click “Save and Continue”; just uploading the paper is not sufficient. After the last step, you should see a confirmation that the submission is complete. You should also receive an e-mail confirmation. For inquiries regarding the submission of your paper on ScholarOne Manuscripts, please contact [email protected] or call +1 732 465 5861.

ScholarOne Manuscripts will accept files for review in various formats. Please check the guidelines of the specific journal for which you plan to submit.

You will be asked to file an electronic copyright form immediately upon completing the submission process (authors are responsible for obtaining any security clearances). Failure to submit the electronic copyright could result in publishing delays later. You will also have the opportunity to designate your article as “open access” if you agree to pay the IEEE open access fee.

Final Stage Using ScholarOne Manuscripts

Upon acceptance, you will receive an email with specific instructions regarding the submission of your final files. To avoid any delays in publication, please be sure to follow these instructions. Most journals require that final submissions be uploaded through ScholarOne Manuscripts, although some may still accept final submissions via email. Final submissions should include source files of your accepted manuscript, high quality graphic files, and a formatted pdf file. If you have any questions regarding the final submission process, please contact the administrative contact for the journal.

In addition to this, upload a file with complete contact information for all authors. Include full mailing addresses, telephone numbers, fax numbers, and e-mail addresses. Designate the author who submitted the manuscript on ScholarOne Manuscripts as the “corresponding author.” This is the only author to whom proofs of the paper will be sent.

Copyright Form

An IEEE copyright form should accompany your final submission. You can get a .pdf, .html, or .doc version at
. Authors are responsible for obtaining any security clearances.

Editorial Policy

Submission of a manuscript is not required for participation in a conference. Do not submit a reworked version of a paper you have submitted or published elsewhere. Do not publish “preliminary” data or results. The submitting author is responsible for obtaining agreement of all coauthors and any consent required from sponsors before submitting a paper. The IEEE Transactions and Journals Department strongly discourages courtesy authorship. It is the obligation of the authors to cite relevant prior work.

The IEEE Transactions and Journals Department does not publish conference records or proceedings. The department does publish papers related to conferences that have been recommended for publication on the basis of peer review. As a matter of convenience and service to the technical community, these topical papers are typically collected and published in one special issue of most transactions publications.

At least two reviews are required for every paper submitted. For conference-related papers, the decision to accept or reject a paper is made by the conference editors and publications committee; the recommendations of the referees are advisory only. Indecipherable English is a valid reason for rejection. There is a service available that will help you improve your English for a fee, and the link to that service can be found at Authors of rejected papers may revise and resubmit them as regular papers, whereupon they will be reviewed by two new referees.

Publication Principles

The two types of contents of that are published are; 1) peer-reviewed and 2) archival. The Transactions and Journals Department publishes scholarly articles of archival value as well as tutorial expositions and critical reviews of classical subjects and topics of current interest.

Authors should consider the following points:

1) Technical papers submitted for publication must advance the state of knowledge and must cite relevant prior work.

2) The length of a submitted paper should be commensurate with the importance, or appropriate to the complexity, of the work. For example, an obvious extension of previously published work might not be appropriate for publication or might be adequately treated in just a few pages.

3) Authors must convince both peer reviewers and the editors of the scientific and technical merit of a paper; the standards of proof are higher when extraordinary or unexpected results are reported.

4) Because replication is required for scientific progress, papers submitted for publication must provide sufficient information to allow readers to perform similar experiments or calculations and use the reported results. Although not everything need be disclosed, a paper must contain new, useable, and fully described information. For example, a specimen’s chemical composition need not be reported if the main purpose of a paper is to introduce a new measurement technique. Authors should expect to be challenged by reviewers if the results are not supported by adequate data and critical details.

5) Papers that describe ongoing work or announce the latest technical achievement, which are suitable for presentation at a professional conference, may not be appropriate for publication.


Basic format for books:

J. K. Author, “Title of chapter in the book,” in Title of His Published Book, xth ed. City of Publisher, Country if not

USA: Abbrev. of Publisher, year, ch. x, sec. x, pp. xxx–xxx.


G. O. Young, “Synthetic structure of industrial plastics,” in Plastics, 2nd ed., vol. 3, J. Peters, Ed. New York: McGraw-Hill, 1964, pp. 15–64.

W.-K. Chen, Linear Networks and Systems. Belmont, CA: Wadsworth, 1993, pp. 123–135.

Basic format for periodicals:

J. K. Author, “Name of paper,” Abbrev. Title of Periodical, vol. x, no. x, pp. xxx-xxx, Abbrev. Month, year.


J. U. Duncombe, “Infrared navigation—Part I: An assessment
of feasibility,” IEEE Trans. Electron Devices, vol. ED-11, no. 1, pp. 34–39, Jan. 1959.

E. P. Wigner, “Theory of traveling-wave optical laser,” Phys. Rev.,
vol. 134, pp. A635–A646, Dec. 1965.

E. H. Miller, “A note on reflector arrays,” IEEE Trans. Antennas Propagat., to be published.

Basic format for reports:

J. K. Author, “Title of report,” Abbrev. Name of Co., City of Co., Abbrev. State, Rep. xxx, year.


E. E. Reber, R. L. Michell, and C. J. Carter, “Oxygen absorption in the earth’s atmosphere,” Aerospace Corp., Los Angeles, CA, Tech. Rep. TR-0200 (4230-46)-3, Nov. 1988.

J. H. Davis and J. R. Cogdell, “Calibration program for the 16-foot antenna,” Elect. Eng. Res. Lab., Univ. Texas, Austin, Tech. Memo. NGL-006-69-3, Nov. 15, 1987.

Basic format for handbooks:

Name of Manual/Handbook, x ed., Abbrev. Name of Co., City of Co., Abbrev. State, year, pp. xxx-xxx.


Transmission Systems for Communications, 3rd ed., Western Electric Co., Winston-Salem, NC, 1985, pp. 44–60.

Motorola Semiconductor Data Manual, Motorola Semiconductor Products Inc., Phoenix, AZ, 1989.

Basic format for books (when available online):

Author. (year, month day). Title. (edition) [Type of medium]. volume (issue). Available: site/path/file


J. Jones. (1991, May 10). Networks. (2nd ed.) [Online]. Available:

Basic format for journals (when available online):

Author. (year, month). Title. Journal. [Type of medium]. volume (issue), pages. Available: site/path/file


R. J. Vidmar. (1992, Aug.). On the use of atmospheric plasmas as electromagnetic reflectors. IEEE Trans. Plasma Sci. [Online]. 21(3), pp. 876–880. Available:

Basic format for papers presented at conferences (when available online):

Author. (year, month). Title. Presented at Conference title. [Type of Medium]. Available: site/path/file


PROCESS Corp., MA. Intranets: Internet technologies deployed behind the firewall for corporate productivity. Presented at
INET96 Annual Meeting. [Online]. Available:

Basic format for reports and handbooks (when available online):

Author. (year, month). Title. Comp an y . C ity, State or Country. [Type of Medium]. Available: site/path/file


S. L. Tall een. (1996 , Apr . ). The In t r an et Archi -tecture: M a nagi ng i n f o rm at i on i n t h e ne w paradigm. Amdahl Corp., CA. [Online]. Available:

Basic format for computer programs and electronic documents (when available online): ISO recommends that capitalization follow the accepted practice for the language or script in which the information is given.


A. Harriman. (1993, June). Compendium of genealogical software. Humanist. [Online]. Available e-mail: [email protected] Message: get GENEALOGY REPORT

Basic format for patents (when available online):

Name of the invention, by inventor’s name. (year, month day). Patent Number [Type of medium]. Available: site/path/file


Musical toothbrush with adjustable neck and mirror, by L.M.R. Brooks. (1992, May 19). Patent D 326 189

[Online]. Available: NEXIS Library: LEXPAT File: DESIGN

Basic format for conference proceedings (published):

J. K. Author, “Title of paper,” in Abbreviated Name of Conf., City of Conf., Abbrev. State (if given), year, pp. xxxxxx.


D. B. Payne and J. R. Stern, “Wavelength-switched pas- sively coupled single-mode optical network,” in Proc. IOOC-ECOC, 1985,
pp. 585–590.

Example for papers presented at conferences (unpublished):

D. Ebehard and E. Voges, “Digital single sideband detection for interferometric sensors,” presented at the 2nd Int. Conf. Optical Fiber Sensors, Stuttgart, Germany, Jan. 2-5, 1984.

Basic format for patents:

J. K. Author, “Title of patent,” U.S. Patent x xxx xxx, Abbrev. Month, day, year.


G. Brandli and M. Dick, “Alternating current fed power supply,”
U.S. Patent 4 084 217, Nov. 4, 1978.

Basic format for theses (M.S.) and dissertations (Ph.D.):

J. K. Author, “Title of thesis,” M.S. thesis, Abbrev. Dept., Abbrev. Univ., City of Univ., Abbrev. State, year.

J. K. Author, “Title of dissertation,” Ph.D. dissertation, Abbrev. Dept., Abbrev. Univ., City of Univ., Abbrev. State, year.


J. O. Williams, “Narrow-band analyzer,” Ph.D. dissertation, Dept. Elect. Eng., Harvard Univ., Cambridge, MA, 1993.

N. Kawasaki, “Parametric study of thermal and chemical nonequilibrium nozzle flow,” M.S. thesis, Dept. Electron. Eng., Osaka Univ., Osaka, Japan, 1993.

Basic format for the most common types of unpublished references:

J. K. Author, private communication, Abbrev. Month, year.

J. K. Author, “Title of paper,” unpublished.

J. K. Author, “Title of paper,” to be published.


A. Harrison, private communication, May 1995.

B. Smith, “An approach to graphs of linear forms,” unpublished.

A. Brahms, “Representation error for real numbers in binary computer arithmetic,” IEEE Computer Group Repository, Paper R-67-85.

Basic format for standards:

Title of Standard, Standard number, date.


IEEE Criteria for Class IE Electric Systems, IEEE Standard 308, 1969.

Letter Symbols for Quantities, ANSI Standard Y10.5-1968.

First A. Author
(M’76–SM’81–F’87) and the other authors may include biographies at the end of regular papers. Biographies are often not included in conference-related papers. This author became a Member (M) of IEEE in 1976, a Senior Member (SM) in 1981, and a Fellow (F) in 1987. The first paragraph may contain a place and/or date of birth (list place, then date). Next, the author’s educational background is listed. The degrees should be listed with type of degree in what field, which institution, city, state, and country, and year the degree was earned. The author’s major field of study should be lower-cased.

The second paragraph uses the pronoun of the person (he or she) and not the author’s last name. It lists military and work experience, including summer and fellowship jobs. Job titles are capitalized. The current job must have a location; previous positions may be listed without one. Information concerning previous publications may be included. Try not to list more than three books or published articles. The format for listing publishers of a book within the biography is: title of book (city, state: publisher name, year) similar to a reference. Current and previous research interests end the paragraph.

The third paragraph begins with the author’s title and last name (e.g., Dr. Smith, Prof. Jones, Mr. Kajor, Ms. Hunter). List any memberships in professional societies other than the IEEE. Finally, list any awards and work for IEEE committees and publications. If a photograph is provided, the biography will be indented around it. The photograph is placed at the top left of the biography, and should be of good quality, professional-looking, and black and white (see above example). Personal hobbies will be deleted from the biography. Following are two examples of an author’s biography.

Second B. Author
was born in Greenwich Village, New York City, in 1977. He received the B.S. and M.S. degrees in aerospace engineering from the University of Virginia, Charlottesville, in 2001 and the Ph.D. degree in mechanical engineering from Drexel University, Philadelphia, PA, in 2008.

From 2001 to 2004, he was a Research Assistant with the Princeton Plasma Physics Laboratory. Since 2009, he has been an Assistant Professor with the Mechanical Engineering Department, Texas A&M University, College Station. He is the author of three books, more than 150 articles, and more than 70 inventions. His research interests include high-pressure and high-density nonthermal plasma discharge processes and applications, microscale plasma discharges, discharges in liquids, spectroscopic diagnostics, plasma propulsion, and innovation plasma applications. He is an Associate Editor of the journal Earth, Moon, Planets, and holds two patents.

Mr. Author was a recipient of the International Association of Geomagnetism and Aeronomy Young Scientist Award for Excellence in 2008, the IEEE Electromagnetic Compatibility Society Best Symposium Paper Award in 2011, and the American Geophysical Union Outstanding Student Paper Award in Fall 2005.

Third C. Author, Jr. (M’87) received the B.S. degree in mechanical engineering from National Chung Cheng University, Chiayi, Taiwan, in 2004 and the M.S. degree in mechanical engineering from National Tsing Hua University, Hsinchu, Taiwan, in 2006. He is currently pursuing the Ph.D. degree in mechanical engineering at Texas A&M University, College Station.

From 2008 to 2009, he was a Research Assistant with the Institute of Physics, Academia Sinica, Tapei, Taiwan. His research interest includes the development of surface processing and biological/medical treatment techniques using nonthermal atmospheric pressure plasmas, fundamental study of plasma sources, and fabrication of micro- or nanostructured surfaces.

Mr. Author’s awards and honors include the Frew Fellowship (Australian Academy of Science), the I. I. Rabi Prize (APS), the European Frequency and Time Forum Award, the Carl Zeiss Research Award, the William F. Meggers Award and the Adolph Lomb Medal (OSA).




How to Use the IEEEtran LATEX Class
Michael Shell, Member, IEEE

(Invited Paper)

Abstract—This article describes how to use the IEEEtran class
with LATEX to produce high quality typeset papers that are suit-
able for submission to the Institute of Electrical and Electronics
Engineers (IEEE). IEEEtran can produce conference, journal
and technical note (correspondence) papers with a suitable choice
of class options. This document was produced using IEEEtran
in journal mode.

Index Terms—Class, IEEEtran, LATEX, paper, style, template,


W ITH a recent IEEEtran class file, a computer runningLATEX, and a basic understanding of the LATEX language,
an author can produce professional quality typeset research
papers very quickly, inexpensively, and with minimal effort.
The purpose of this article is to serve as a user guide of
IEEEtran LATEX class and to document its unique features and

This document applies to version 1.8 and later of IEEEtran.
Prior versions do not have all of the features described here.
IEEEtran will display the version number on the user’s console
when a document using it is being compiled. The latest version
of IEEEtran and its support files can be obtained from IEEE’s
web site [1], or CTAN [2]. This latter site may have some
additional material, such as beta test versions and files related
to non-IEEE uses of IEEEtran. See the IEEEtran homepage
[3] for frequently asked questions and recent news about

Complimentary to this document are the files1 bare_con
f.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex and b
are_jrnl_transmag.tex, which are “bare bones” example
(template) files of a conference, journal, Computer Society
journal2 and TRANSACTIONS ON MAGNETICS paper, respec-
tively. Authors can quickly obtain a functional document by
using these files as starters for their own work. A more
advanced example featuring the use of optional packages along

Manuscript created February 25, 2002; revised December 27, 2012. This
work was supported by the IEEE. This work is distributed under the LATEX
Project Public License (LPPL) ( ) version 1.3. A
copy of the LPPL, version 1.3, is included in the base LATEX documentation of
all distributions of LATEX released 2003/12/01 or later. The opinions expressed
here are entirely that of the author. No warranty is expressed or implied. User
assumes all risk.

See for current contact information.
1Note that it is the convention of this document not to hyphenate command

or file names and to display them in typewriter font. Within such
constructs, spaces are not implied at a line break and will be explicitly carried
into the beginning of the next line. This behavior is not a feature of IEEEtran,
but is used here to illustrate computer commands verbatim.

2Computer Society conferences are not sufficiently different from traditional
conferences to warrant a separate example file.

with more complex usage techniques, can be found in bare_

It is assumed that the reader has at least a basic working
knowledge of LATEX. Those so lacking are strongly encouraged
to read some of the excellent literature on the subject [4]–[6].
In particular, Tobias Oetiker’s The Not So Short Introduction
to LATEX 2ε [5], which provides a general overview of working
with LATEX, and Stephan M. Moser’s How to Typeset Equations
in LATEX [6], which focuses on the formatting of IEEE-style
equations using IEEEtran’s IEEEeqnarray commands, are both
available for free online.

General support for LATEX related questions can be obtained
in the internet newsgroup comp.text.tex. There is also a
searchable list of frequently asked questions about LATEX [7].

Please note that the appendices sections contain information
on installing the IEEEtran class file as well as tips on how to
avoid commonly made mistakes.


There are a number of class options that can be used to
control the overall mode and behavior of IEEEtran. These are
specified in the traditional LATEX way. For example,

is used with correspondence (technote) papers. The various
categories of options will now be discussed. For each category,
the default option is shown in bold. The user must specify an
option from each category in which the default is not the one
desired. The various categories are totally orthogonal to each
other—changes in one will not affect the defaults in the others.

A. 9pt, 10pt, 11pt, 12pt
There are four possible values for the normal text size.

10pt is used by the vast majority of papers. Three notable
exceptions are technote papers, which use 9pt text, the initial
submissions to some conferences that use 11pt, and Computer
Society papers which typically require 12pt text.

B. draft, draftcls, draftclsnofoot, final
IEEEtran provides for three draft modes as well as the

normal final mode. The draft modes provide a larger (double)
line spacing to allow for editing comments as well as one
inch margins on all four sides of the paper. The standard draft
option puts every package used in the document into draft
mode. With most graphics packages, this has the effect of
disabling the rendering of figures. If this is not desired, one
can use the draftcls option instead to yield a draft mode that
will be confined within the IEEEtran class so that figures will

0000–0000/00$00.00 c© 2012 Michael Shell


be included as normal. draftclsnofoot is like draftcls, but does
not display the word “DRAFT” along with the date at the
foot of each page. Both draft and draftclsnofoot modes imply
draftcls (which is a subset of the other two). When using one
of the draft modes, most users will also want to select the
onecolumn option.

C. conference, journal, technote, peerreview, peerreviewca
IEEEtran offers five major modes to encompass conference,

journal, correspondence (technote) and peer review papers.
Journal and technote modes will produce papers very similar
to those that appear in many IEEE TRANSACTIONS journals.
When using technote, most users should also select the 9pt
option. The peerreview mode is much like the journal mode,
but produces a single-column cover page (with the title, author
names and abstract) to facilitate anonymous peer review. The
title is repeated (without the author names or abstract) on the
first page after the cover page.3 Papers using the peer review
options require an IEEEpeerreviewmaketitle command
(in addition to and after the traditional maketitle) to be
executed at the place the cover page is to end—usually just
after the abstract. This command will be silently ignored
with the non-peerreview modes. See the bare template files
for an example of the placement of this command. The
peerreviewca mode is like peerreview, but allows the author
name information to be entered and formatted as is done
in conference mode (see Section IV-B2 for details) so that
author affiliation and contact information is more visible to
the editors.

1) Conference Mode Details: Conference mode makes a
number of significant changes to the way IEEEtran behaves:

• The margins are increased as the height of the text is
reduced to about 9.25in. In particular, the bottom margin
will become larger than that of the top as IEEE wants
extra clearance at the bottom. The text height will not be
exactly 9.25in, but will vary slightly with the normal font
size to ensure an integer number of lines in a column.

• Headings and page numbers are not displayed in the
headers or footers. This, coupled with symmetric hori-
zontal margins, means that there will not be a noticeable
difference between the one and two sided options.

• The author text is placed within a tabular environment
to allow for multicolumn formatting of author names and
affiliations. Several commands are enabled to facilitate
this formatting (see Section IV-B2 for details).

• The spacing after the authors’ names is reduced. So is
the spacing around the section names.

• The special paper notice (if used) will appear between the
author names and the title (not after as with journals).

• The figure captions are centered.
• The following commands are intentionally disabled: t
hanks, IEEEPARstart, IEEEbiography, IEEEb
iographynophoto, IEEEpubid, IEEEpubidadjco
l, IEEEmembership, and IEEEaftertitletext. If

3A blank page may be inserted after the cover page when using the twoside
(duplex printing) option so that the beginning of the paper does not appear
on the back side of the cover page.

needed, they can be reenabled by issuing the command:

• Various reminder (related to camera ready work) and
warning notices are enabled.

When using conference mode, most users will also want to
equalize the columns on the last page (see Section XIV).

D. compsoc, transmag

These mutually exclusive options invoke special modes by
which IEEEtran produces the format of the publications of
the IEEE Computer Society and TRANSACTIONS ON MAG-
NETICS, respectively. Neither of these are enabled by default.

1) Compsoc Mode: Notable compsoc mode format features

• the default text font is changed from Times Roman
to Palatino/Palladio (non-conference compsoc modes

• revised margins;
• Arabic section numbering;
• enabling of the IEEEcompsocitemizethanks and I
EEEcompsocthanksitem commands to provide for the
thanks (first footnote) itemized list used for author

• enabling of the IEEEtitleabstractindextext com-
mand to provide for single column abstract and index
terms (see Section V);

• various other styling changes such as the use of: a sans
serif (Helvetica) font for titles, headings, etc.; a ruled
line above the first footnote area; left aligned reference
labels; etc.

a) Compsoc Conference Mode: IEEEtran follows the
published guidelines for IEEE Computer Society conference
papers [8]. Perhaps surprisingly, this format nullifies many of
the unique features of compsoc journals and is not so much
different from traditional conference mode. However, Arabic
section numbering is retained. It should be mentioned that
Scott Pakin’s IEEEconf LATEX class [9] also produces this

2) Transmag Mode: For the transmag mode:

• The text within author should be entered as the long
form under conference mode;

• enabling of the IEEEtitleabstractindextext com-
mand to provide for single column abstract and index
terms (see Section V);

• IEEEauthorrefmark will produce arabic author affil-
iation symbols;

• subsection and subsubsection headings and/or their spac-
ings are slightly different;

• a smaller, bold font than normal is used for the title.

The transmag mode (as well as the standard journal mode)
is also acceptable for submission to IEEE Magnetics Letters.
Authors who wish to have their figures and tables appear at
the end of the paper can use the endfloat.sty [10] package to
achieve this.


E. letterpaper, a4paper

IEEEtran supports both US letter (8.5in × 11in) and A4
(210mm × 297mm) paper sizes. Since IEEE primarily uses
US letter, authors should usually select the letterpaper option
before submitting their work to IEEE—unless told otherwise
(typically by conferences held outside the United States).
Changing the paper size will not alter the typesetting of the
document—only the margins will be affected. In particular,
documents using the a4paper option will have reduced side
margins (A4 is narrower than US letter) and a longer bottom
margin (A4 is longer than US letter). For both cases, the top
margins will be the same and the text will be horizontally

Note that authors should ensure that all post-processing
(ps, pdf, etc.) uses the same paper specification as the .tex
document. Problems here are by far the number one reason
for incorrect margins. See Appendix B for more details.

F. oneside, twoside

These options control whether the layout follows that of
single sided or two sided (duplex) printing. Because the side
margins are normally centered, the main notable difference is
in the format of the running headings.

G. onecolumn, twocolumn

These options allow the user to select between one and two
column text formatting. Since IEEE always uses two column
text, the onecolumn option is of interest only with draft papers.

H. romanappendices

IEEEtran defaults to numbering appendices alphabetically
(e.g., A, B, etc.). Invoke this option to get Roman numbering.

I. captionsoff

Invoking this option will inhibit the display of captions
within figures and tables. This is done in a manner that
preserves the operation of label within caption. This
option is intended for journals, such as IEEE TRANSACTIONS
ON POWER ELECTRONICS (TPE), that require figures and
tables to placed, captionless, on pages of their own at the
end of the document. Such figure placement can be achieved
with the help of the endfloat.sty package [10]:


Note that the TPE has other unusual formatting requirements
that also require the draftclassnofoot and onecolumn options
as well as the insertion of page breaks (newpage) just prior
to the first section as well as the bibliography. Such commands
can be enabled conditionally via the ifCLASSOPTIONcapt
ionsoff conditional (Section III-A).

J. nofonttune

IEEEtran normally alters the default interword spacing to
be like that used in IEEE publications. The result is text that
requires less hyphenation and generally looks more pleasant,
especially for two column text. The nofonttune option will
disable the adjustment of these font parameters. This option
should be of interest only to those who are using fonts
specifically designed or modified for use with two column


IEEEtran offers three catagories of special commands that
allow information to be passed between the class file and the
user’s document:

• CLASSINPUTs are inputs that provide a way to cus-
tomize the operation of IEEEtran by overriding some of
the default settings (at the time IEEEtran is loaded);

• CLASSOPTIONs which are outputs that allow for condi-
tional compilation based on which IEEEtran class options
have been selected;

• CLASSINFOs which are outputs that allow the user a
way to access additional information about the IEEEtran
runtime environment.


The available CLASSINPUTs include: CLASSINPUTbase
linestretch which sets the line spacing of the document;
CLASSINPUTinnersidemargin which sets the margin at
the inner (binding) edge; CLASSINPUToutersidemargin
which sets the margin at the outer edge; CLASSINPUTtopt
extmargin which sets the top margin; CLASSINPUTbotto
mtextmargin which sets the bottom margin. Of course, such
parameters can be set via the traditional LATEX interface (odd
sidemargin, topmargin, etc.). However, the advantage of
of using the CLASSINPUT approach is that it allows IEEEtran
to adjust other internal parameters and perform any additional
calculations as needed. For example, setting the side margins
in LATEX requires a careful setting of oddsidemargin, e
vensidemargin and textwidth taking into consideration
the paper size and whether or not duplex (two-sided) printing
is being used.

To invoke a CLASSINPUT, just define the relavant CLASS-
INPUT as desired prior to the loading of IEEEtran. For


will yield a document that has 17mm side margins—if only
one of the innerside/outerside (or toptext/bottomtext) margin
pair is specified, IEEEtran will assume the user wants sym-
metric side (or top/bottom) margins and will set both values
of the relavant pair to the (single) user specified value.

IEEEtran uses the fixed values of 12pt and 0.25in for h
eadheight and headsep, respectively. The position of
the header can be altered after IEEEtran is loaded, without
changing the margins as long as the sum of topmargin,


headheight and headsep is preserved. For example, the
header can be shifted upwards 0.2in using:

Likewise, footskip, which has a default value of 0.4in, can
easily be changed to alter the position of the footer within the
bottom margin.

When using CLASSINPUTbaselinestretch, IEEEtran
will automatically “digitize” textheight so that an integer
number of lines will fit on a page (as is done in the draft
modes). Digitization is not done when the top or bottom
margins are set via CLASSINPUTs. Users are cautioned that
using CLASSINPUT controls can result in documents that
are not compliant with the IEEE’s standards. The intended
applications include: (1) conferences or societies that have
unusual formatting requirements; (2) producing copies with
nonstandard margins such as when binding for personal use;
and (3) non-IEEE related work.


CLASSOPTIONs are primarily TEX if conditionals that
are automatically set based on which IEEEtran options are
being used. Thus, for example, a construct such as

typeout{in conference mode}

typeout{not in conference mode}

can be used to provide for conditional code execution. Please
note that, as mentioned in Section II-B, the draft and draft-
clsnofoot options imply draftcls. So, most users will want to
test ifCLASSOPTIONdraftcls for detecting the draft

For the document’s point size options, CLASSOPTIONp
t is defined as a macro that expands to the numerical part
of the selected point value (e.g., 9, 10, 11 or 12). For the
paper size options, CLASSOPTIONpaper will be a macro
that contains the paper specification (e.g., letter, a4). To use
these as conditionals will require a string macro comparison:

typeout{document is 9pt}

Users should treat the CLASSOPTIONs as being “read-only”
and not attempt to manually alter their values because IEEE-
tran uses them internally as flags to determine which options
have been selected—changing these flags will likely result in
improper formatting.


The available CLASSINFOs include the ifCLASSINFOp
df conditional which works much like Heiko Oberdiek’s if-
pdf.sty package [11] to indicate if PDF output (from pdfLATEX)
is in effect:
typeout{PDF mode}


IEEEtran.cls also provides the lengths CLASSINFOnorma
lsizebaselineskip, which is the baselineskip of the
normalsize font, and CLASSINFOnormalsizeunitybaseli
neskip, which is the baselineskip of the normalsize font
under unity baselinestetch.

Finally, there are the string macros (these are not condition-
als or lengths) CLASSINFOpaperwidth and CLASSINF
Opaperheight which contain the paper dimensions in their
native specifications including units (e.g., 8.5in, 22mm, etc.).
As with CLASSOPTIONs, users should not attempt to alter


The parts of the document unique to the title area are created
using the standard LATEX command maketitle. Before this
command is called, the author must declared all of the text
objects which are to appear in the title area.

A. Paper Title

The paper title is declared like:
title{A Heuristic Coconut-based Algorithm}

in the standard LATEX manner. Line breaks (\) may be used
to equalize the length of the title lines. Do not use math or
other special symbols in the title.

B. Author Names

The name and associated information is declared with the
author command. author behaves slightly differently
depending on the document mode.

1) Names in Journal/Technote Mode: A typical author
command for a journal or technote paper looks something like
} John˜Doe,˜IEEEmembership{Fellow,˜OSA,} and˜Jane˜D
thanks{Manuscript received January 20, 2002; revise
d January 30, 2002. This work was supported by the I
thanks{M. Shell is with the Georgia Institute of Te

The IEEEmembership command is used to produce the
italic font that indicates the authors’ IEEE membership status.
The thanks command produces the “first footnotes.” Be-
cause the LATEX thanks was not designed to contain multiple
paragraphs4, authors will have to use a separate thanks
for each paragraph. However, if needed, regular line breaks
(\) can be used within thanks. In order to get proper line
breaks and spacing, it is important to correctly use and control
the spaces within author. Use nonbreaking spaces (˜) to
ensure that name/membership pairs remain together. A minor,
but easy, mistake to make is to forget to prevent unwanted
spaces from getting between commands which use delimited
({}) arguments. Note the two % which serve to prevent the
code line break on lines ending in a } from becoming an
unwanted space. Such a space would not be ignored as an

4Although IEEEtran.cls does support it, the standard classes do not.


end-of-line space because, technically, the last thanks is
the final command on the line. “Phantom” spaces like these
would append to the end of the last author’s name, causing
the otherwise centered name line to shift very slightly to the

2) Names in Conference Mode: The author name area
is more complex when in conference mode because it also
contains the authors’ affiliations. For this reason, when in
conference mode, the contents of author{} are placed
into a modified tabular environment. The commands IE
EEauthorblockN{} and IEEEauthorblockA{} are also
provided so that it is easy to correctly format the author names
and affiliations, respectively. For papers with three or less
affiliations, a multicolumn format is preferred:
author{IEEEauthorblockN{Michael Shell}
IEEEauthorblockA{School of Electrical and\
Computer Engineering\
Georgia Institute of Technology\
Atlanta, Georgia 30332–0250\
Email: [email protected]}
IEEEauthorblockN{Homer Simpson}
IEEEauthorblockA{Twentieth Century Fox\
Springfield, USA\
Email: [email protected]}
IEEEauthorblockN{James Kirk\
and Montgomery Scott}
IEEEauthorblockA{Starfleet Academy\
San Francisco, California 96678-2391\
Telephone: (800) 555–1212\
Fax: (888) 555–1212}}

Use and to separate the affiliation columns. The columns
will automatically be centered with respect to each other and
the side margins.

If there are more than three authors and/or the text is too
wide to fit across the page, use an alternate long format:
author{IEEEauthorblockN{Michael ShellIEEEauthorre
fmark{1}, Homer SimpsonIEEEauthorrefmark{2}, James K
irkIEEEauthorrefmark{3}, Montgomery ScottIEEEautho
rrefmark{3} and Eldon TyrellIEEEauthorrefmark{4}}
IEEEauthorblockA{IEEEauthorrefmark{1}School of Ele
ctrical and Computer Engineering\
Georgia Institute of Technology, Atlanta, Georgia 30
Email: [email protected]}
IEEEauthorblockA{IEEEauthorrefmark{2}Twentieth Cen
tury Fox, Springfield, USA\
Email: [email protected]}
IEEEauthorblockA{IEEEauthorrefmark{3}Starfleet Aca
demy, San Francisco, California 96678-2391\
Telephone: (800) 555–1212, Fax: (888) 555–1212}
IEEEauthorblockA{IEEEauthorrefmark{4}Tyrell Inc.,
123 Replicant Street, Los Angeles, California 90210


The IEEEauthorrefmark{} command will generate a foot-
note symbol corresponding to the number in its argument. Use
this to link the author names to their respective affiliations. It is
not necessary prevent spaces from being between the IEEEa
uthorblock’s because each block starts a new group of lines
and LATEX will ignore spaces at the very end and beginning of

3) Names in Compsoc Journal Mode: One unique feature
of Computer Society journals is that author affiliations are for-
matted in an itemized list within the first (thanks) footnote.

In compsoc mode, IEEEtran provides a special form of tha
nks, IEEEcompsocitemizethanks, to obtain this effect:

} John˜Doe,˜IEEEmembership{Fellow,˜OSA,} and˜Jane˜D
IEEEcompsocitemizethanks{IEEEcompsocthanksitem M.
Shell is with the Georgia Institute of Technology.
IEEEcompsocthanksitem J. Doe and J. Doe are with An
onymous University.}%
thanks{Manuscript received January 20, 2002; revise
d January 30, 2002.}}

Within IEEEcompsocitemizethanks, IEEEcompsoctha
nksitem works like item to provide a bulleted affiliation
group. To facilitate dual compilation, in non-compsoc mode,
IEEEtran treats IEEEcompsocitemizethanks as thanks
and sets IEEEcompsocthanksitem to generate a line break
with indentation. However, this is not entirely satisfactory as
Computer Society journals place the author affiliations before
the “manuscript received” line while traditional IEEE journals
use the reverse order. If correct dual compilation is needed,
the CLASSOPTION conditionals can be employed to swap
the order as needed.

4) Names in Compsoc Conference Mode: Names in comp-
soc conference mode are done in the same way as traditional
conference mode. However, because the compsoc conference
mode uses much larger margins, there is typically room for
only two (rather than three) affiliation columns before the
alternate single column format is required.

5) Names in Transmag Journal Mode: TRANSACTIONS ON
MAGNETICS papers typically use the conference long format
for author names, but try to keep each name and address
pair on one line and without any email addresses or phone
numbers. Also, thanks is available under transmag journal
mode even though the names are entered much like the long
format under conference mode. See the file bare_jrnl_tr
ansmag.tex for an example of author entry under transmag

C. Running Headings

The running headings are declared with the markboth{
}{} command. The first argument contains the journal name
information and the second contains the author name and paper
title. For example:

markboth{Journal of Quantum Telecommunications,˜Vol
.˜1, No.˜1,˜January˜2025}{Shell MakeLowercase{text
it{et al.}}: A Novel Tin Can Link}

Note that because the text in the running headings is automat-
ically capitalized, the MakeLowercase{} command must be
used to obtain lower case text. The second argument is used
as a page heading only for the odd number pages after the
title page for two sided (duplex) journal papers. This page is
such an example. Technote papers do not utilize the second
argument. Conference papers do not have running headings,
so markboth{}{} has no effect when in conference mode.
Authors should not put any name information in the headings
(if used) of anonymous peer review papers.


D. Publication ID Marks

Publication ID marks can be placed on the title page of
journal and technote papers via the IEEEpubid{} command:

IEEEpubid{0000–0000/00$00.00˜copyright˜2012 IEEE

Although authors do not yet have a valid publication ID at the
time of paper submission, IEEEpubid{} is useful because it
provides a means to see how much of the title page text area
will be unavailable in the final publication. This is especially
important in technote papers because, in some journals, the
publication ID space can consume more than one text line. If
IEEEpubid{} is used, a second command, IEEEpubidad
jcol must be issued somewhere in the second column of the
title page. This is needed because LATEX resets the text height
at the beginning of each column. IEEEpubidadjcol “pulls
up” the text in the second column to prevent it from blindly
running into the publication ID.

Publication IDs are not to be placed by the author on camera
ready conference papers so IEEEpubid{} is disabled in
conference mode. Instead the bottom margin is automatically
increased by IEEEtran when in conference mode to give IEEE
room for such marks at the time of publication. In draft mode,
the publisher ID mark will not be printed at the bottom of the
titlepage, but room will be cleared for it.

Publication ID marks are perhaps less important with
compsoc papers because Computer Society journals place the
publisher ID marks within the bottom margin so as not to
affect the amount of page space available for text.

E. Special Paper Notices

Special paper notices, such as for invited papers, can be
declared with:

IEEEspecialpapernotice{(Invited Paper)}

Special paper notices in journal and technote papers appear
between the author names and the main text. The title page
of this document has an example. For conference papers, the
special paper notice is placed between the title and the author

Much more rarely, there is sometimes a need to gain access
to the space across both columns just above the main text.
For instance, a paper may have a dedication [12]. IEEEtran
provides the command IEEEaftertitletext{} which can
be used to insert text or to alter the spacing between the title
area and the main text:


Authors should be aware that IEEEtran carefully calculates
the spacing between the title area and main text to ensure that
the main text height of the first page always is equal to an
integer number of normal sized lines (unless the top or bottom
margins have been overridden by CLASSINPUTs). Failure to
do this can result in underfull vbox errors and paragraphs
being “pulled apart” in the second column of the first page
if there isn’t any rubber lengths (such as those around section
headings) in that column. The contents of IEEEaftertitle
text{} are intentionally allowed to bypass this “dynamically

determined title spacing” mechanism, so authors may have to
manually tweak the height (by a few points) of the IEEEa
ftertitletext{} contents (if used) to avoid an underfull
vbox warning.


The abstract is generally the first part of a paper after m
aketitle. The abstract text is placed within the abstract

We propose …

Math, special symbols and/or citations should generally not
be used in abstracts.5

Journal and technote papers also have a list of key words
(index terms) which can be declared with:

Broad band networks, quality of service, WDM.

To obtain a list of valid keywords from the IEEE, just send a
blank email to [email protected] A list of Computer Society
approved keywords can be obtained at
org/mc/keywords/keywords.htm. Do not use math or special
symbols in the keywords.

The Computer Society and TRANSACTIONS ON MAGNET-
ICS formats present a difficulty in that compsoc and transmag
journal (but not compsoc conference) papers place the abstract
and index terms sections in single column format just below
the author names, but the other IEEE formats place them in
the first column of the main text before the first section. To
handle this, IEEEtran offers a command, IEEEtitleabstr
actindextext, that is to be declared before maketitle,
and whose single argument holds the text/sections that are to
appear in single column format after the author names:

We propose …
Broad band networks, quality of service, WDM.

To facilitate dual compilation, IEEEtran provides another
command, IEEEdisplaynontitleabstractindextext,
which will “become” whatever was declared in IEEEtitl
eabstractindextext when in non-compsoc, non-transmag
or conference mode (as compsoc conferences use the same
placement for the abstract and index terms as traditional
conferences do). That is to say, the abstract and index terms
sections can be automatically “teleported’ to the appropriate
place they need to be depending on the document mode. IE
EEdisplaynontitleabstractindextext should typically
be placed just after maketitle (and before IEEEpeerre
viewmaketitle if used).

5That said, if it is permitted or required, be aware that in order to preserve
the distinction between constructs such as vector and scalar forms, IEEEtran
defaults to using non-bold math within the abstract. However, bold math better
matches the bold text font used for the abstract text. If a bold math font is
desired, just issue a boldmath command at the start of the abstract.



Sections and their headings are declared in the usual LATEX
fashion via section, subsection, subsubsection,
and paragraph. In the non-compsoc modes, the numbering
for these sections is in upper case Roman numerals, upper case
letters, Arabic numerals and lower case letters, respectively.
In compsoc mode, Arabic numerals are used exclusively for
(sub)section numbering.

The paragraph section is not allowed for technotes or
compsoc conferences as these generally are not permitted to
have such a deep section nesting depth. If needed, paragra
ph can be restored by issuing the command setcounter{
secnumdepth}{4} in the document preamble.

A. Initial Drop Cap Letter

The first letter of a journal paper is a large, capital, oversized
letter which descends one line below the baseline. Such a
letter is called a “drop cap” letter. The other letters in the first
word are rendered in upper case. This effect can be accurately
produced using the IEEEtran command IEEEPARstart{}{
}. The first argument is the first letter of the first word, the
second argument contains the remaining letters of the first
word. The drop cap of this document was produced with:


Note that some journals will also render the second word in
upper case—especially if the first word is very short. For more
usage examples, see the bare_jrnl.tex example file.


Citations are made with the cite command as usual.
IEEEtran will produce citation numbers that are individually
bracketed in IEEE style. (“[1], [5]” as opposed to the more
common “[1, 5]” form.) The base IEEEtran does not sort or
produce compressed “ranges” when there are three or more
adjacent citation numbers. However, IEEEtran pre-defines
some format control macros to facilitate easy use with Donald
Arseneau’s cite.sty package [13]. So, all an author has to do
is to call cite.sty:


and the adjacent citation numbers will automatically be sorted
and compressed (ranged) IEEE style. (Of course, multiple
adjacent citations should always all be declared within a
single cite, comma separated, for this to work.) Invoke
cite.sty’s noadjust option to prevent an unwanted leading space
from occurring should a citation ever need to be enclosed in

One complication in compsoc mode is that the Computer
Society does not compress, but does sort, adjacent citation
numbers. Version 4.0 and later of cite.sty provides a nocom-
press option that disables compression, but preserves sorting.

% requires cite.sty v4.0 or later (November 2003)



can be used with universal applicability.
Note that, if needed (e.g., next to a non-punctuation/non-

space character), cite.sty’s cite command will automatically
add a leading space. i.e., “(cite{mshell01})” will become
like “( [1])”. If this behavior is not desired, use the cite
package’s noadjust option (cite.sty V3.8 and later) which will
turn off the added spaces:


cite also allows for an optional note (e.g., cite[Th.
7.1]{mshell01}). If the cite with note has more than

one reference, the note will be applied to the last of the listed
references. It is generally desirable that if a note is given, only
one reference should be listed in that cite.


Equations are created using the traditional equation envi-

x = sumlimits_{i=0}^{z} 2^{i}Q

which yields

x =


2iQ. (1)

Use the displaymath environment instead if no equation
number is desired. When referring to equations, articles in
IEEE publications do not typically use the word “equation,”
but rather just enclose the equation number in parentheses,

… as can be seen in (ref{eqn_example}).

IEEE’s two column format puts serious constraints on how
wide an equation can be. So, a fair portion of the effort in
formatting equations usually has to be devoted to properly
breaking them. It is the author’s responsibility to ensure
that all equations fit into the given column width. In rare
circumstances, it is possible to have a few equations that span
both columns (see Section X-D1), but the vast majority of
over-length equations have to be broken across multiple lines.


Perhaps the most convenient and popular way to pro-
duce multiline equations is LATEX 2ε’s eqnarray environment.
However, eqnarray has several serious shortcomings:

1) the use of 2×arraycolsep for a column separation
space does not provide natural math spacing in the
default configuration;

2) column definitions cannot be altered;
3) it is limited to three alignment columns;
4) column alignment cannot be overridden within individ-

ual cells.
There are a number of vastly superior packages for format-
ting multiline mathematics. Perhaps the most popular is the



Size Width Cmd. Used for Example

small 1/6 em , symbols ab
medium 2/9 em : binary operators a + b

large 5/18 em ; relational operators a = b
negative small −1/6 em ! misc. uses ab

amsmath package [14]. Amsmath is a comprehensive work
which contains many helpful tools besides enhanced multiline
alignment environments. So, all authors should give serious
consideration to its use—regardless of what they use to gen-
erate aligned equations. One thing to be aware of is that, upon
loading, amsmath will configure LATEX to disallow page breaks
within multiline equations (even within non-amsmath defined
environments). The philosophy here is that author should
manually insert breaks where desired so as to ensure that
breaks occur only at acceptable points. To restore IEEEtran’s
ability to automatically break within multiline equations, load
amsmath like:


It is strongly recommended that the amsmath option cmex10
be used. Without this option, current versions of amsmath may
employ fonts for some of the smaller sizes (such as can occur
with math in footnotes) that are available only in bitmap form
(for most TEX systems). Thus, the cmex10 option will ensure
that it is possible (i.e., necessary, but not sufficient) to produce
a document that uses only Type 1 fonts—as required for IEEE
Xplore compliance.

Another extremely powerful set of alignment tools, one
of which is a totally rewritten eqnarray environment, is
provided by mathenv.sty which is part of Mark Wooding’s
MDW Tools [15].

Finally, IEEEtran provides a fully integrated custom IEEEe-
qnarray family of commands (see Appendix F) that are de-
signed to have almost universal applicability for many different
types of alignment situations.

Nevertheless, it is instructive to show a simple example
using the standard eqnarray in order to explain some of
the fine points of math spacing under LATEX. As shown in
Table I, TEX normally draws from four different spacings when
typesetting mathematics. In order to produce precise (and
correct) mathematical alignments, it is crucial to understand
how to control such spacing. Consider a multiline equation

Z = x1 + x2 + x3 + x4 + x5 + x6

+a + b (1)
+a + b (2)
+ a + b (3)
+ a + b (4)

(in typical IEEE style) which was produced by

Z&{}={}&x_1 + x_2 + x_3 + x_4 + x_5 + x_6nonumber\

&&+a + b\
&&+{}a + b\
&&{}+a + b\
&&{+}:a + b

Lines one through four show some possible ways the + a + b
line could be implemented.6 Only number four is the correct
way for most IEEE purposes. In TEX’s math mode, spacing
around operators can be inhibited by enclosing them within
braces (e.g., {=}) or forced by surrounding them with “empty
ords” (e.g., {}={}). It is important to understand that the
empty ords do not have width themselves. However, their
presence causes TEX to place space around the operators as if
they were “next to something.” With this in mind, the first step
in the example is to set arraycolsep to zero to prevent eq
narray from putting in the unwanted, artificial, inter-column
spacing. Placing empty ords around the equal sign then forces
the correct natural spacing. Alternatively, arraycolsep
could have been set to 0.14 em and the empty ords around the
equal sign eliminated.7 It is important to remember to restore
arraycolsep to its default value of 5 pt after the eqnarr
ay is complete as other environments (such as array) depend
on it. (Alternatively, the structure could have been enclosed in
a group of braces to keep the change local—which has the
added advantage of not requiring that the user remember what
the correct default value is.)

The first line is incorrect because a is being indicated as
a positive quantity rather than something that must be added
to the previous line. (i.e., the + is being treated as a unary,
rather than a binary, operator.) In line two, adding an empty
ord to the right side of the plus sign does nothing, except
to demonstrate that empty ords have zero width. Adding an
empty ord to the left side of the plus sign (line three) does
engage binary spacing, but causes an unwanted8 right shift
of the line. Finally, manually adding a medium space to the
right side only of the plus sign in line four does the trick. The
suppression of automatic spacing around the plus sign ({+}) is
unneeded in this case, but may be required in other alignment
environments that “expand” such operators by default.

Another way around the spacing problem is to use only
two alignment columns (as is done by amsmath.sty’s alig
n). e.g., in the previous example, “Z =” would be contained
in the first column.

A. Cases Structures
Incidentally, the numcases (or subnumcases) environ-

ments in Donald Arseneau’s cases.sty package [16] should be
used when “cases” structures in which each branch can be
referenced with a different equation (or subequation) number
are needed:

|x| =
x, for x ≥ 0 (5a)
−x, for x < 0 (5b)

6In this example, the equation numbering system is (ab)used to identify

7This assumes that 1 em in the text font has the same width as 1 em in the
math font. For the standard fonts, this is indeed the case.

8IEEE normally wants all of the lines left aligned, but there are cases when
such an indention may be desirable.


because those built from the array or amsmath cases envi-
ronments will have a single equation number that encompasses
both branches.

Authors should keep in mind when choosing an appropriate

optional placement argument for the figure/table environments
that most IEEE journals strongly favor the positioning of
floats to the top of the page and rarely, if ever, use bottom
floats. Computer Society journals also favor top floats, but
do occasionally employ bottom floats. Furthermore, IEEE
journals never place floats in the first column of the first page
and rarely (if ever) do they do so in the second column of the
first page. Middle in-text placement (“here”) is not used.

Note that LATEX 2ε’s float routine places footnotes above
bottom floats. To change this so that footnotes appear below
the bottom floats (as IEEE does) invoke the fnbelowfloa
t command provided by Sigitas Tolušis’ stfloats package [17]
(see Section X-D for more features of the stfloats package).

A. Figures

Figures handled in the standard LATEX manner. For example:
caption{Simulation Results.}

Note that (1) figures should be centered via the LATEX cent
ering command—this is a better approach than using the ce
nter environment which adds unwanted vertical spacing; (2)
the caption follows the graphic; and (3) any labels must be
declared after (or within) the caption command.

When referring to figures in typical IEEE papers, authors
should use the abbreviation “Fig.”, but in Computer Society
conference papers they should use the full word “Figure”.
IEEEtran provides the string macro figurename which
contains the correct name to use for the given formatting mode.

The includegraphics command is the modern, pre-
ferred, way of including images and provides a flexible in-
terface that makes it easy to scale graphics to size. To use it,
the graphics or graphicx (the latter is recommended) must first
be loaded.

It is strongly recommended that authors be familiar with the
graphics package documentation [18] as well as Keith Reck-
dahl’s excellent Using Imported Graphics in LATEX 2ε [19]. The
reader is reminded that the “draftcls” or “draftclsnofoot”, not
“draft”, class option must be selected in order to get draft
papers with visible figures.

As explained in Appendix D, Encapsulated PostScript (EPS)
or Portable Document Format (PDF) is the preferred graph-
ics format for LATEX work. Furthermore, the user’s draw-
ing/graphing application should be capable of outputing di-
rectly in EPS (or PDF) vector form (which will not degrade
or pixelize when magnified)—although photos will likely have
to be in (EPS/PDF) bitmap form.

The psfrag package [20] might also be of interest. Psfrag
allows the user to “go into” an EPS graphic and replace text

strings contained in it with real LATEX code. In this manner,
LATEX’s extensive support of mathematical symbols and fonts
can be extended to figures made with applications with more
modest glyph support. Using psfrag does require the use of the
dvips DVI to PostScript conversion step (not pdfLATEX’s PDF
mode) as some of the features of the PostScript language have
to be utilized.9 pdfLATEX users can use psfrag by “preprocess-
ing” their figures by importing them into a dummy document
using psfrag, running LATEX followed by dvips, then converting
the PostScript output to a PDF graphic for direct importation
into the main document which is then processed by pdfLATEX.
There is additional usage information on psfrag in the Using
Imported Graphics in LATEX 2ε guide [19].

1) Subfigures: Subfigures can be obtain via the use of
Steven Douglas Cochran’s subfigure [21] or subfig [22] pack-
ages. Be forewarned that the former is no longer being
maintained and, although self-contained and compatible with
IEEEtran, is becoming incompatible with an increasing num-
ber of other LATEX packages including fixltx2e.sty. For this
reason, subfigure.sty is not recommended for new work and
will not be covered here.

It is important to note that subfig.sty package options are
usually required to obtain IEEE compliant subfigure captions.
Furthermore, compsoc format requires a larger sans serif font
than the serif footnote size font used in traditional IEEE for-
matting. There is a further complication with subfig.sty in that
this package depends on caption.sty, which, in its default con-
figuration, will overrride IEEEtran’s handling of captions—
resulting in non-IEEE style main captions. To prevent this,
be sure to invoke subfig.sty’s caption=false option, which
has been available since version 1.3 (2005/06/28). Thus, the
recommended way to load subfig.sty is:



Because multiple (sub)figures usually require more width
than is available in a single column, subfigures are often used
within the double column figure environment (Section X-D):

subfloat[Case I]{includegraphics[width=2.5in]{subf
subfloat[Case II]{includegraphics[width=2.5in]{sub
caption{Simulation results.}

Note how captions can be tagged to each of the subfigures as
well as to the overall figure via an optional argument to the s
ubfloat command. However, most IEEE authors/journals do
not employ subfigure captions, but instead reference/describe

9PDF is much like a subset of PostScript—the latter is a Turing complete
programming language, the former is not.



First Next

1.0 2.0

all of the subfigures (a), (b), etc., within the main caption.
hfil is used as a subfigure separator to achieve equal
spacing around the graphics. More complex implementations
are possible. Note that the total width of all the subfigures on
a line must be less than the text width or else an unwanted
line break will occur. Multiple lines of subfigures can be used
within a figure if needed. See the subfig.sty documentation as
well as the Using Imported Graphics in LATEX 2ε guide [19]
for more details.

Axel Sommerfeldt’s modern and actively maintained sub-
caption.sty package [23] can not be recommended at this time
because it does not provide an option to prevent the underlying
caption.sty from taking control of main caption formatting
away from IEEEtran.

B. Algorithms

IEEE publications use the figure environment to contain
algorithms that are not to be a part of the main text flow.
Peter Williams’ and Rogerio Brito’s algorithmic.sty package
[24] or Szász János’ algorithmicx.sty package [25] (the latter is
designed to be more customizable than the former) may be of
help in producing algorithm-like structures (although authors
are of course free to use whatever LATEX commands they are
most comfortable with in this regard). However, do not use
the floating algorithm environment of algorithm.sty (also by
Williams and Brito) or algorithm2e.sty (by Christophe Fiorio)
as the only floating structures IEEE uses are figures and tables.
Furthermore, IEEEtran will not be in control of the (non-IEEE)
caption style produced by the algorithm.sty or algorithm2e.sty
float environments.

C. Tables

Tables are handled in a similar fashion, but with a few
notable differences. For example, the code
caption{A Simple Example Table}
bfseries First & bfseries Next\
1.0 & 2.0\

results in Table II. Note that IEEE places table captions before
the tables. Within the table environment, the default text size
is footnotesize which is what IEEE typically uses for tables.
When using the tabular environment to construct tables, it is
usually a good idea to increase the value of arraystretch
above unity to “open up” the table rows a tad. Also, IEEE often


AND Mu(H) + HX a

H(Mu) + F2 H(Mu) + Cl2

β(H) 80.9◦b 83.2◦

β(Mu) 86.7◦ 87.7◦

a for the abstraction reaction, Mu + HX →
MuH + X.

b 1 degree = π/180 radians.

uses tables with “open sides,” (without vertical lines along
each side) although the “closed side” form (e.g., Table I) is
more commonly used for the tables within this document.

Unfortunately, the standard LATEX 2ε tabular environment
has a number of shortcomings. Two notable problems are (1)
the corners where lines meet are improperly formed; and (2) it
is not very flexible in terms of user control. For these reasons,
authors are urged to look into some of the other packages
for making tables. A good one that provides revised “drop-in
replacements” for both the tabular and array environments is
Frank Mittelbach’s and David Carlisle’s array package [26].
Even more powerful (and complex) is the tabular and array
environments provided by the mdwtab.sty package which is
part of Mark Wooding’s MDW Tools [15].

As an alternative, IEEEtran offers the IEEEeqnarraybox
command which can also be used to produce tables10 of high
quality. See Appendix F for more details.

1) Footnotes Within Tables: Footnotes normally cannot be
placed directly within some commands and environments such
as parbox, tabular, etc., because they become “trapped”
inside. One way around this is to split the place the footnote
marker (footnotemark) is located (within the table) from
where the footnote text itself is declared (outside of the table
using footnotetext).

Another approach is to use the footnote.sty package (which
is part of Mark Wooding’s MDW Tools [15]) which allows
environments to be configured so as not to trap footnotes:


Note that is probably not a good idea to use footnotes in
floating structures (like table) because the position of each
can move relative to one another. To put the footnote at the
end of a table instead of at the bottom of the page, just
enclose tabular, etc., inside a minipage (no footnote package
needed). A very good approach for handling footnotes within
tables (including those that float) is to use Donald Arseneau’s
threeparttable package [27] which was used to generate Table
III (the code of which is an example in the threeparttable.sty

D. Double Column Floats

LATEX’s figure* and table* environments produce fig-
ures and tables that span both columns. This capability is
sometimes needed for structures that are too wide for a single

10Table I was made using this command.


It is a limitation of the LATEX 2ε kernel that double column
floats cannot be placed at the bottom of pages. That is to
say “begin{figure*}[!b]” will not normally work as
intended. Authors that need this capability should obtain and
load Sigitas Tolušis’ stfloats package [17] which patches the
LATEX 2ε output routine to allow it to handle double column
floats at the bottom of pages. Please note that stfloats is a
very invasive package which may not work with versions of
LATEX other than the standard LATEX 2ε release and may cause
problems with other packages that modify the output and/or
float routines (such as those that balance columns, alter the
placement of floating figures, etc.). IEEE authors are warned
not to use packages that allow material to be placed across the
middle of the two text columns (such as cuted.sty, midfloat.sty,
etc.) as IEEE does not do this.

Another LATEX 2ε limitation (patched with stfloats or not) is
that double column floats will not appear on the same page
where they are defined. So, the user will have to define such
things prior to the page on which they are to (possibly) appear.

LATEX 2ε (patched with stfloats or not) does not attempt
to keep double and single column floats in sequence with
each other. This can be fixed by loading Frank Mittelbach,
David Carlisle and Chris Rowley’s fixltx2e package (already
installed on most LATEX systems) [28]. Note that fixltx2e.sty
is the replacement (and superset) of the older fix2col.sty [28].
However, fixltx2e/fix2col should not be used with the stfloats
package as they both modify some of the same float routines
in different ways.

Morten Høgholm’s dblfloatfix package [29] provides the
combined functionality of both the fixltx2e and stfloats pack-
ages and is now the recommended way to obtain these features.

Finally, authors should also be aware that the LATEX 2ε ker-
nel (patched with stfloats or not) has a long standing limitation
in that it will not allow rubber space that spans both columns
to stretch or shrink as needed for each of the two main text
columns. Therefore, it is possible for double column floats to
cause underfull vbox errors because the remaining text height
may not be equal to an integer number of normal size lines.
The problem can occur in main text columns (on pages with
double column floats) that do not have vertical rubber spacing
(such as that around section headings, equations, etc.) and
results in underfull vbox warnings coupled with paragraphs
that are “pulled apart” from each other. To correct this, users
can manually tweak the amount of space between the double
column structure and main text by inserting a command like


(adjusted as needed) within the double column structure. Inci-
dentally, IEEEtran automatically compensates for this problem
when forming the paper title.

1) Double Column Equations: It is possible, but not pleas-
ant, to use figure* to obtain double column equations. IEEE
rarely uses double column equations because they can waste
space, so this capability is easy to abuse. Authors who are
considering the use of a double column equation should verify
that there are a few examples of such in papers previously
published in the journal they plan to submit to.

There are complications. Although IEEE does not place

constraints on the order of the double column equations
relative to the equations of the main text (that is to say a
set of double column equations can be at the top or bottom
of a page in which they would normally appear in the middle
had they been regular equations), the double column equation
numbers must increase as one progresses down the page (i.e.,
double column equations at the bottom of a page must be
of higher number than those at the top). Furthermore, double
column equations should appear on the same page where they
are referenced (on the page they would have appeared had
they been regular equations). Compounding the difficulty even
further is the fact that LATEX 2ε will not place double column
equations on the same page on which they are defined. Finally,
IEEE does not generally allow other figures or tables to come
between the double column equations and the main text (which
are separated from each other by a rule). All of this means that
the place where a double column equation must be defined has
to be “disconnected” from the place where it will eventually
be referred to in the text—and the user will have to manually
intervene in the equation numbering system.

Therefore, users have to (1) define double column equations
on the page prior to the one that they are to appear; (2) reset
the equation counter when the double column equations are
defined so as not to disturb the regular equation numbers;
(3) manually set the double column equation numbers and (4)
increment the equation counter at the point the double column
equations are referenced in the text so that they are accounted
for in the numbering of the regular equations after that point.

To do all of this, it is convenient to have a “scratch pad”
counter to temporarily save equation numbers. This can be
done via a command such as

in the preamble of the document. Now, the double column
equations are defined on the page prior to the one in which
they are to appear (and in this example supposed that they are
to be equation numbers six and seven):
% ensure that we have normalsize text
% Store the current equation number.
% Set the equation number to one less than the one
% desired for the first equation here.
% The value here will have to changed if equations
% are added or removed prior to the place these
% equations are referenced in the main text.
x = 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 + 21+ 23 + 25
+ 27 + 29 + 31
y = 4 + 6 + 8 + 10 + 12 + 14 + 16 + 18 + 20+ 22 + 24
+ 26 + 28 + 30
% Restore the current equation number.
% IEEE uses as a separator
% The spacer can be tweaked to stop underfull vboxes.


x = 5 + 7 + 9 + 11 + 13 + 15 + 17 + 19 + 21 + 23 + 25 + 27 + 29 + 31 (6)

y = 4 + 6 + 8 + 10 + 12 + 14 + 16 + 18 + 20 + 22 + 24 + 26 + 28 + 30 (7)

The result of which is shown at the top of this page. This
technique allows the definition of the equations to be posi-
tioned arbitrarily as needed so that the (floating) equations
will appear where desired. The “[!t]” option forces LATEX to
do its best to place the equations at the top of the next page.
Had it been “[!b]” instead, then the stfloats package would
need to be loaded and the vspace command, followed by
the hrulefill command, would have to occur before the
equations in the figure.

The double column equations can then been referenced in
the main text like:

% The previous equation was number five.
% Account for the double column equations here.
As can be seen in (ref{eqn_dbl_x}) and
(ref{eqn_dbl_y}) at the top of the page …

Thankfully, double column equations are rare.


The traditional LATEX itemize, enumerate and description
(IED) list environments are ill-suited for producing the style
of lists used in IEEE publications. The main problem is that
they do not provide the user a means for controlling the
parameters of the resultant list. Furthermore, making global
changes to the parameters of the underlying list will result
(often unexpectedly to a user) in the improper behavior of
other commands that depend on it, such as quote. Finally,
LATEX’s list considers the left margin of the list text to be
the reference point that determines how the list is positioned
relative to the left margin of the main text:

labelwidth︷ ︸︸ ︷

labelsep︷ ︸︸ ︷
︸ ︷︷ ︸


List Text

This contrasts with IEEE lists which use the label box as
the reference point for the list structure. i.e., for a given
circumstance, the list labels will be indented by a certain
amount, the list text block will be indented from the label
boxes by a given amount and these spacings will determine
the position of the list text.

For these reasons, IEEEtran provides enhanced IED list
environments that make it much easier to produce IEEE style
lists. The underlying list remains the same as in traditional
LATEX so as not to break code that depends upon it. IEEEtran
uses a new length variable, IEEElabelindent, so that users
can specify IED list structures directly in IEEE fashion:

︸ ︷︷ ︸

labelwidth︷ ︸︸ ︷

labelsep︷ ︸︸ ︷
List Text

The IEEEtran IED lists ignore all “external” changes to the list
length parameters. Instead, IED lists are controlled exclusively
via two interfaces:

1) “global” control via the IEEEiedlistdecl command;

2) “local” control via an optional argument that can be
provided to itemize, enumerate, and descrip

For example, declaring


in an IEEEtran document will set the default width of the
label boxes in all later IED lists to be equal to the width
of “Hello”. Note: Because setting a labelwidth is so
commonly performed, IEEEtran provides a command: IEEE
setlabelwidth{X} which is a shorter form of: settowid

The local control is used if the parameters are to apply only
to an individual IED list:


Within an IED list, the local control is executed just after the
global control and therefore, the commands in the local control
can both augment and countermand those in the global control.
Please note that the code in the local and global controls are
executed in the same manner as normal LATEX code. Therefore,
the user should ensure that unwanted blank spaces do not
appear in the controls. If a control definition is too long to
fit on one line, shield the end of lines with “%” to prevent
them from being interpreted as blanks (Section IV-B1 has
some information on this topic). Also, note that the LATEX
parser requires that braces be placed around commands with
optional arguments that are placed directly within the optional
arguments of other commands:


This IEEEtran IED implementation makes it easy to control
IED lists, even when they are deeply nested.

The default spacings the IED lists use are stored in various
length (not macro) commands. Changes to these “master”
defaults are rarely needed and should be done only at the
beginning of the document, not in the IED list controls. These
constants will now be briefly explained.
IEEEilabelindent: This length is the default amount

the itemized list label boxes are indented from the left margin.
IEEE seems to use at least two different values. For example,
NICATIONS, they tend to use an indention equal to parinde
they tend to indent itemized lists a little more (1.3parind


ent). The shorter length is stored as IEEEilabelindentA
and the longer as IEEEilabelindentB. The default is to
use the shorter version. To use the longer version do a

at the beginning of the document.
IEEEelabelindent: This length is the default amount

the enumerated list label boxes are indented from the left
margin. Normally, the same as parindent.
IEEEdlabelindent: Ditto for description list labels. Nor-

mally, the same as parindent.
IEEEiednormlabelsep: This length is the normal de-

fault spacing between the IED list label boxes and the list
IEEEiedmathlabelsep: For nomenclature description

lists (a list of math symbols and their explanations), IEEE
usually increases the separation between the terms and the
definitions. This length is set to the longer than normal length.
To invoke its use, just issue the command IEEEusemathla
belsep in a list control.
IEEEiedtopsep: This length is the extra vertical separa-

tion put above and below each IED list. IEEE usually puts
a little extra spacing around each list. However, this extra
spacing is barely noticeable.
IEEElabelindentfactori through IEEElabelinden

tfactorvi: These contain the factors by which the effective
IEEElabelindent is reduced as the list nesting depth
increases. IEEE normally decreases the amount of indention as
the list nesting level increases because there isn’t much room
to indent with two column text. IEEEtran has an “automatic
indention cut-back” feature that provides this behavior. The
actual amount the label boxes will be indented is IEEEla
belindent multiplied by the IEEElabelindentfactorX
corresponding to the level of nesting depth (where “X” is the
nesting depth in roman numerals). This provides a means by
which the user can alter the effective IEEElabelindent
for deeper levels. There may not be such a thing as correct
“standard IEEE” values. What IEEE actually does may depend
on the specific circumstances. The first list level almost always
has full indention. The second levels usually have only 75%
of the normal indentation. Third level and greater nestings
are very rare, and probably don’t use any indentation. These
factors are not lengths, but rather constant macros like bas
elinestretch so renewcommand should be used if they
need to be changed. The default values are
IEEElabelindentfactori 1.0
IEEElabelindentfactorii 0.75
IEEElabelindentfactoriii 0.0
IEEElabelindentfactoriv 0.0
IEEElabelindentfactorv 0.0
IEEElabelindentfactorvi 0.0

The use of these factors in IED lists may be suspended by
issuing the command IEEEnolabelindentfactortrue in
a list control (which has the same effect as setting all the
indent factors to 1.0).

Normally, IEEEtran automatically calculates leftmargin
based upon the current values of IEEElabelindent, labe
lwidth and labelsep. To stop this auto-calculation so that
a manually specified value of leftmargin is used instead,

just use IEEEnocalcleftmargintrue in a list control. This
feature should not be needed during the course of normal IEEE
related work.

IEEEtran provides a means to manually specify the justifica-
tion within the IED list label boxes. The commands IEEEied
labeljustifyl, IEEEiedlabeljustifyc and IEEEied
labeljustifyr can be used in a list control to justify the list
labels to the left, center, and right sides, respectively. Itemize
and enumerate lists automatically default to right justification,
while description defaults to left justification. The justification
commands should not be needed during the course of normal
IEEE related work.

In addition to modifying the behavior of itemize, enumer
ate and description, IEEEtran also provides the respective
aliases IEEEitemize, IEEEenumerate and IEEEdescript
ion, which provides a way for the user to access the IEEE
style list environments even in the event another package is
loaded that overrides the IED list environments. For special-
ized applications, the original LATEX IED list environments are
retained as LaTeXitemize, LaTeXenumerate and LaTeXde

A. Itemize

The itemized lists will normally automatically calculate the
width of whatever symbol the current list level is using so that
a user can just call begin{itemize}…end{itemize}
without doing anything special. Furthermore, the auto-label-
width feature will work properly even if labelitemX has
been redefined (where “X” indicates “i,ii, .. iv”, whichever
is appropriate) before the list begins. However, if any item
symbols are to be specified via item[X] (this is rare and may
well be nonstandard as far as IEEE related work is concerned),
then the following form can be used:

item[X] blah
item[Y] blah

where “Z” is the longest label in the list.

B. Enumerate

The important thing to note about enumerated lists is that
the labelwidth will default to the length of “9)” in the
normal size and style. Therefore, the width of the longest label
will have to be manually specified if any of the following
conditions are true:

1) a top level list has more than 9 items;
2) a relevant labelenumX or theenumX has been rede-

3) item[X] has been used to manually specify labels;
4) the labels are using a font that is not the normal size

and style;
5) the enumerated list is nested (i.e., not at the top level)

and is therefore not using Arabic digits as labels.
For example:


item blah
item blah
% 12 items total

C. Description
Generally speaking, the longest label width will always have

to be specified for description lists. Furthermore, the author
may wish to use IEEEmathlabelsep for labelsep when
building a math symbol list. For example:
item[$gammadeltabeta$] Is the index of..
item[$alphaomegapithetamu$] Gives the..

Sometimes it can be difficult to ascertain from inspection
which of the labels is the longest. For such cases, a little
diagnostic code may be helpful to measure a length and then
to display the result on the console:
newlength{mydiaglen} % put in preamble

Theorems and related structures such as axioms, corollaries

and lemmas, are handled in the traditional LATEX fashion. The
user must first declare the structure name via the

command where struct_type is the user chosen identifier
for the structure, struct_title is the heading that is used for
the structure and in_counter is an optional name of a counter
whose number will be displayed with the structure number
and whose update will reset the structure counter. Most IEEE
papers use sequential theorem numbering throughout the entire
work, so an in_counter is usually not specified. However,
those papers that do use in_counter usually use “section”
such that the section number is the first part of each theorem
number. After the structure is defined it can be used via

where extra_title is an optional name that is displayed
with the structure.

For example, the most common way to do theorems would
be to use

followed as needed by environments like

Sometimes it is desirable that a structure share its counter
with another structure. This can be accomplished by using the
alternate form of newtheorem


where num_like is the name of an existing structure.
IEEE theorem numbers are prefixed by the section number

they were defined in (e.g., 2.5). This presents a difficulty with
appendices (especially when numbered with Roman numerals)
because the theorem numbers will not be unique. To remedy
this, within Roman numbered appendices, IEEEtran will add
an “A” prefix (e.g., A2.5). For Alpha number appendices,
theorem numbering is more straightforward (e.g., A.5, B.5,
etc.). For a single appendix, a constant “A” prefix is used (e.g.,

A. Proofs

Proofs are easily handled by the predefined IEEEproof


The Q.E.D. symbol “ ” is automatically placed at the end of
each proof. If needed, the symbol can be manually accessed
via the IEEEQED command. Both the closed (default) “ ”
and open “ ” forms are provided as IEEEQEDclosed and
IEEEQEDopen, respectively. To change the default from
closed to open (some journals and/or authors prefer the open
form), just redefine IEEEQED as desired:


IEEEproof also supports an optional argument which allows
the default string “Proof” to be overridden:

begin{IEEEproof}[Proof of Theorem ref{thm:my}]


A. Appendices

The appendix command is used to start a single appendix.
An optional argument can be used to specify a title:

appendix[Proof of the Zonklar Equations]

After issuing appendix, the section command will be
disabled and any attempt to use section will be ignored
and will cause a warning message to be generated. (The
single appendix marks the end of the enumerated sections
and the section counter is fixed at zero—one does not state
“see Appendix A” when there is only one appendix, instead
“see the Appendix” is used.) However, all lower subsecti
on commands and the section* form will work as normal
as these may still be needed for things like acknowledgments.
appendices is used when there is more than one ap-

pendix section. section is then used to declare each ap-

section{Proof of the First Zonklar Equation}

The mandatory argument to section can be left blank (sect
ion{}) if no title is desired. It is important to remember to
declare a section before any additional subsections or labels
that refer to section (or subsection, etc.) numbers. As with a


ppendix, the section* command and the lower subsec
tion commands will still work as usual.

There are two appendix numbering conventions used by
IEEE. Capital letters (e.g., “Appendix B”) and Roman nu-
merals (e.g., “Appendix II”). The former appears to be more
popular and is the IEEEtran default. Use the IEEEtran class
option romanappendices to get Roman numbered appendices.

Some authors prefer to have the appendix number to be part
of equation numbers for equations that appear in an appendix.
This can be accomplished by redefining the equation numbers


before the first appendix equation. For a single appendix, the
constant “A” should be used in place of thesection.

B. Acknowledgements

Acknowledgements and other unnumbered sections are cre-
ated using the section* command:


The second, optional, command is needed to manually add
such sections to the table of contents (which is rarely used,
but some authors may do so with draft papers) as well as the
document’s PDF bookmarks (if using hyperref.sty).

C. Bibliographies

Bibliographies are most easily (and correctly) generated
using the IEEEtran BIBTEX package [30] which is easily
invoked via


See the IEEEtran BIBTEX package documentation for more

When submitting the document source (.tex) file to external
parties, it is strongly recommended that the BIBTEX .bbl file
be manually copied into the document (within the traditional
LATEX bibliography environment) so as not to depend on
external files to generate the bibliography and to prevent the
possibility of changes occurring therein.

D. Biographies

Biographies for journal articles are created using the IEEE-
biography environment which supports an optional argument
for the inclusion of a photo:


Note the extra set of braces that are required to prevent the
LATEX parser from becoming confused when commands with
optional arguments are used within an optional argument of
another command. Alternatively, a LATEX macro (command)

could be defined to facilitate a shorthand notation for the
author photos. If the optional argument is not used, space will
be reserved for a photo and the message “PLACE PHOTO
HERE” will be displayed in place of a photo.

IEEEtran is a tad overly cautious about preventing the
IEEEbiography photo area from being broken across pages.
If it looks as though a IEEEbiography should be able to be
“squeezed” at the end of a page, but instead it begins on a
new page, try inserting


or so before the IEEEbiography and see if it can fit.
IEEE’s algorithm for spacing around biographies can be a

tad complex because esthetics must be considered. IEEEtran
places vfil above biographies. This allows the user to shove
biographies down or up as desired by placing the infinitely
more stretchable vfill before or after the biographies.

The photo area is 1 in wide and 1.25 in long. IEEE recom-
mends that author photo images should be of 220 dpi (dots per
inch) resolution and in gray scale with 8 bits/sample.

If no photo is available, the IEEEbiographynophoto
environment, which does not support an optional argument
or reserve space for a photo, can be used instead.


IEEE (coarsely) equalizes the lengths of the columns on the
last page. The balance is coarse in the sense that reference or
IEEEbiography entries are not usually broken—so the column
lengths are not usually perfectly equal.

Balancing the last two columns is especially important for
camera ready work. It is recommended that authors use the
manual approach by putting in newpage at the appropriate
point or enlargethispage{-X.Yin} somewhere at the top
of the first column of the last page where “X.Yin” is the
amount to effectively shorten the text height of the given page.

Sometimes such a command has to be located between
bibliography entries. This can be a problem because, although
the command can be placed within the .bbl file, it will get
overwritten the next time BIBTEX is run. For this situation,
IEEEtran offers a way to invoke commands just before a given
reference number via the IEEEtriggeratref{} command.
For instance, issuing the command


before the bibliography will insert a page break just before
reference number ten. The command that is executed defaults
to newpage. However, this can be changed via the IEEE
triggercmd command:


Note that manually set break points or page sizes will have to
be readjusted if the document content ever changes.

There are LATEX packages, such as balance.sty [31] and
flushend.sty [32], that are designed to automatically balance
the columns on the last page. Flushend does not require the
placement of any special command in the first column of the
last page, balance.sty may. However, the use of these packages
is not recommended because they are known to be less than


perfectly reliable in their operation. The author of balance.sty
does not guarantee that it will work with every possible type
of page, especially pages with figures. Under certain circum-
stances, flushend.sty will cause a spacing anomaly between
two lines within a reference in the second column of the last
page (becomes larger than the space between references). This
problem seems to result because the bibliography in IEEEtran
is a list with zero space between the list items which are in
footnotesize. The problem can also occur under article.cls for
the same type of list. It may be possible to manually correct
the flushend anomaly by tweaking the spacer at the column
break via a flushend command such as “atColsBreak{vs
kip-2pt}”, but having to do so partially defeats the purpose
of using the package in the first place. If using flushend.sty or
balance.sty, be sure to check the document carefully for any
spacing problems—especially on the last page.


First of all, users should be aware that, depending on the
target operating system of the IEEEtran archive packaging
(e.g., .tar.gz for Unix, or .zip for MS Windows), the plain text
based IEEEtran files (.bst, .cls, .sty, .tex, etc.) may use one of
two different types of end-of-line character conventions. Unix
(including Mac OS X) systems use line feed <lf> (0x0A),
while MS Windows systems use carriage return/line feed pairs
<cr><lf> (0x0D 0x0A) to signal the end of lines.11 Most
modern LATEX systems are tolerant of differing end-of-line
conventions, but some text editors aren’t. (Symptoms here
include text appearing all on one long line, double spacing,

LATEX .cls files can be accessed system-wide when they are
placed in the <texmf>/tex/latex directory, where <tex
mf> is the root directory of the user’s TEX installation. On
systems that have a local texmf tree (<texmflocal>), which
may be named “texmf-local” or “localtexmf”, it may be
advisable to install packages in <texmflocal>, rather than
<texmf> as the contents of the former, unlike that of the
latter, are preserved after the LATEX system is reinstalled and/or

It is recommended that the user create a subdirectory <t
exmf or texmflocal>/tex/latex/IEEE for all IEEE
related LATEX class and package files. On some LATEX systems,
the directory look-up tables will need to be refreshed after
making additions or deletions to the system files. For TEX
Live systems this is accomplished via executing

as root. MiKTEX users can run
initexmf -u

to accomplish the same thing.
Users not willing or able to install the files system-wide can

install them in their personal directories, but will then have to
provide the path (full or relative) in addition to the filename
when referring to them in LATEX.

11The fact that different conventions exist for plain text is, of course, an
absurdity in itself. See the Wikipedia article “Newline” at http://en.wikipedia.
org/wiki/Newline for the history and details.


Some LATEX systems are not properly configured to produce
quality PostScript and/or PDF output. This has historically
been more of a problem with IEEE-related work because the
unique font combination IEEE uses has been known to trigger
problems with some LATEX setups. Fortunately, these types
of problems are now relatively uncommon on modern LATEX

To assist IEEE authors in detecting and correcting prob-
lems with LATEX PostScript/PDF generation, the “Testflow”
diagnostic suite was developed [33]. Authors are encouraged
to take the time to go through the testflow diagnostic and
identify and correct potential problems before their LATEX
systems have to be relied on for production work. Papers with
problems such as incorrect margins, font types, PDF format
errors and/or improper font embedding can incur delays during
the manuscript acceptance process.


A. The acronym.sty Package

Tobias Oetiker’s acronym.sty [34] may be useful with
papers that have a lot of acronyms. However, beware of a
compatibility issue between the acronym environment and the
IEEEtran description lists (see Appendix E).

B. The url.sty Package

Papers that contain URLs, email address, etc., can likely
benefit from the use of Donald Arseneau’s url.sty LATEX
package [35] which provides for more intelligent line breaking
within such structures. Note that IEEEtran.cls automatically
sets the url font style of url.sty to “same” (that is, URLs will
be rendered in the same font as the text they appear in) as
IEEE journals do. To override this, the author must place the
urlstyle after begin{document}.

C. The IEEEtrantools Package

Some of the unique commands provided by the IEEEtran
LATEX class may be of use in non-IEEE related work using
other class files (e.g., dissertations, technical reports, etc.).
The IEEEtrantools.sty package [36] provides several popular
IEEEtran commands including IEEEPARstart, the IEEE
style IED list environments, the IEEEeqnarray family of
commands, the IEEEproof environment and IEEEauthor
refmark. The IEEEtrantools package is not needed under,
and should not be loaded with, the IEEEtran class. See the
IEEEtrantools documentation for more details.


Many user mistakes with IEEEtran involve doing too much
rather than too little. Older class files may have required hacks
in order to get the formatting closer to that of IEEE. These
tweaks are no longer needed. Users should carefully check
all the loaded packages to ensure that they are still useful


under the latest version of IEEEtran. Don’t load packages just
because “this is the way it always has been done.” The same
is true for manually adjusted spacing, margins, paper sizes,

Below are a few of the more commonly encountered mis-
takes to avoid.

Placing labels before captions: This is considered to be
one of the most frequent mistakes made in LATEX of all time.
Remember that label must be placed after or within cap
tion to be able to reference figures/tables properly. As it is
caption that actually sets up the reference counter, labe
l’s placed prior to caption will refer to the section number,
instead of the desired figure/table number.

Altering the default fonts: Authors should allow IEEEtran
to manage the fonts. Do not attempt to use packages that
override the default fonts such as pslatex, mathptm, etc.

Altering the default spacings, section heading styles,
margins or column style: Authors should not attempt to
manually alter the margins, paper size (except as provided
in IEEEtran class options) or use packages that do so (geom-
etry.sty, etc.). There should be no need to add spacing around
figures, equations, etc., (except possibly for double column
floats as described in Section X-D).

Using bitmapped graphics for line art: LATEX has always
favored the use of Encapsulated PostScript (EPS) or under
pdfLATEX, Portable Document Format (PDF), (which can be
considered to be a type of subset of PostScript), for graphics
(see Section X-A for more information), and for good reason.
EPS/PDF supports both vector (that is, containing objects such
as lines, circles, etc., that are mathematically described) and
bitmap (that is, containing only samples in the form of pixels)
images. The former should always be used for drawings,
graphs, charts, etc., while the latter usually has to be employed
with photos (because their contents usually cannot be easily
described mathematically). The drawing and graphing tools
used by the author should be capable of outputting directly12

in vector (EPS or PDF) format. Vector EPS/PDF images can be
scaled, rotated and magnified without undergoing degradation
such as pixelization or becoming gray or “jaggedy.” For
photos, IEEE recommends the use of EPS/PDF (which is easy
to directly import into (pdf)LATEX in a portable manner) or
TIFF. The use of other graphic formats such as BMP, EMF,
etc., is currently unacceptable for IEEE journals. Some IEEE
conferences may be more liberal with regard to the types of
graphics formats they accept.

Using bitmapped fonts and/or not embedding and
subsetting all document fonts: Authors should check their
system with the testflow diagnostic [33] to ensure that only
vector (Type 1) fonts are being used and that all fonts are
embedded and subsetted. A document that uses bitmapped
fonts and/or fails to contain all (and only) the needed font
glyphs may be rejected by the IEEE. Watch out for graphical
drawing applications that produce output with these problems
(suspect this if the problem goes away when the figures are
not included).

12Once an image in EPS/PDF vector form is converted to a bitmap form
(GIF, TIFF, JPEG, etc.) it will almost always be irretrievably locked into
bitmap form even if it is later converted back into EPS/PDF.

Using older graphics packages: Authors should not use
anything other than the graphics and/or graphicx (preferred)
package for figures. Older interfaces such as psfig, epsf, etc.,
have been obsolete for many years.

Failing to properly divide long equations: It is the author’s
responsibility to ensure that all equations fit within the width of
their columns. Admittedly, breaking an equation is not always
easy to do and two column formatting places serious con-
straints on allowed equation width. However, only the author
can divide his/her equation without unintentionally altering its
meaning or affecting readability. Using subfunctions is a valid
way to reduce to width of an equation, but altering the math
font size is not.

Manually formatting references: Not only is this error
prone, but requires a lot of work as well. It is better to use
the IEEEtran BIBTEX style [30].


acronym.sty: The acronym environment will have a prob-
lem with IEEEtran because of the modified IEEE style
description list environment. The optional argument of the
acronym environment cannot be used to set the width of the
longest label. A workaround is to use IEEEiedlistdecl to
accomplish the same thing:

renewcommand{IEEEiedlistdecl}{relax}% reset back

hyperref.sty: Versions prior to 6.72u will interfere with
the optional argument to appendix. Current versions of
cite.sty (4.01) and hyperref.sty do not work perfectly together
in that citation numbers will not be hyperlinked. If using
hyperref.sty, be sure and use only cite.sty version 4.0 and
later as pervious versions will be overridden by hyperref.sty
resulting in citations that are no longer sorted and compressed.

PCTEX: The commercial PCTEX system seems to be inca-
pable of providing the (common) Times Roman font required
for IEEE work (Computer Modern will be substituted). PCTEX
users are strongly urged to “upgrade” to the free, yet superior,
MiKTEX system [37].

Small caps font variations: The small caps font used in
the free LATEX systems have about 80% the height of normal
sized letters. However, the small caps font IEEE uses in the
journals is slightly smaller with a ratio of around 75%. So, the
widths of the section headings produced under the free LATEX
systems will be slightly wider than that used in actual journals.
The small caps font used in many commercial LATEX systems
(such as those from YandY) has a ratio of about 65%. So,
those systems will produce section headings that are narrower
than those in IEEE publications. Such variations should not
be cause for concern.

Font size of Computer Society journals: Computer Soci-
ety journals seem to be using a font size that is somewhere
between 9pt and 10pt. Thus, 10pt documents formatted with


IEEEtran will have slightly less content per page than actual
IEEE Computer Society journals. The variation is minor and
should not be an issue. Furthermore, the Computer Society
typically requires a standard, and larger, font size for submis-
sion (typically 12pt).


(Optional—for advanced users)

Virtually all LATEX alignment commands such as eqnarr
ay, array and tabular are based on the TEX command
halign. LATEX’s goal of simplifying the use of halign is
noble. However, in hiding much of the lower level interface, a
fair degree of flexibility is lost. This has resulted in the devel-
opment of several packages such as amsmath [14], array.sty
[26], and the MDW tools [15], each of which provides much
more powerful alignment structures.

IEEEtran also provides its own unique set of alignment
tools which are known as the IEEEeqnarray family. The
design philosophy of the IEEEeqnarray family is to provide
a LATEX alignment interface that is based more closely on the
underlying halign, but to couple this with high level col-
umn definition management and automated preamble building
mechanisms (which are tedious to do in TEX). As a result,
the IEEEeqnarray family of commands are flexible enough
to be almost universal replacements for all the other LATEX
commands for producing multiline equations and aligned box
structures such as matrices and tables of text and/or mathe-
matics. Because the user is shielded less from the halign
underpinnings, the rules of operation are more involved. So,
the IEEEeqnarray commands are aimed primarily toward the
more advanced LATEX users.

The use of the IEEEeqnarray family of tools described
in this section is totally optional. The IEEEeqnarray code
is self-contained and does not depend on other alignment
packages—which can be used along side, or in place of, it. The
IEEEtrantools.sty package (See Appendix C-C) is available
for those who wish to use the IEEEeqnarray family outside of

Recommended sources of information on the use of IEEEe-
qnarray include Stephan M. Moser’s How to Typeset Equations
in LATEX [6] and Tobias Oetiker’s The Not So Short Introduction
to LATEX 2ε [5].

A. IEEEeqnarray

The IEEEeqnarray environment is for multiline equations
that occupy the entire column. It is used in much the same
way as eqnarray, but with two additional arguments, one
of which is mandatory and the other is optional:

The optional argument is for commands that are to be executed
within the environment, but before the alignment actually be-
gins. This is just like the local control of the IEEEtran IED list
environments. There is also a global control, IEEEeqnarray


I.D. Description I.D. Description

l left math v vertical rule
c centered math vv two vertical rules
r right math V double vertical rule
L left math with ords VV two double vertical rules
C centered math with ords h horizontal rule
R right math with ords H double horizontal rule
s left text x empty
t centered text X empty math
u right text

Note: S, T, U, p, and P are likely to be used in future versions.


I.D. Width* I.D. Width

! −1/6 em . 0.5arraycolsep
, 1/6 em / 1.0arraycolsep
: 2/9 em ? 2.0arraycolsep
; 5/18 em * 0pt plus 1fil
’ 1 em + 1000pt minus 1000pt
” 2 em – 0pt

* All em values are referenced to the math font.
1 em = quad, 2 em = qquad

decl, which is executed just prior to the local control. By
default, IEEEeqnarraydecl is defined to be relax. As
mentioned in Section XI, users should be careful not to allow
unwanted spaces to occur in these controls because such
things will appear just before the IEEEeqnarray structure.
Furthermore, remember that, to prevent the LATEX parser from
becoming confused, the contents of an optional argument must
be enclosed in braces if the argument contains commands with
optional arguments.

The mandatory argument cols contains the column and
inter-column separator spacing (“inter-column tabskip glue”
in TEXspeak) type specifiers. Column types are identified by
letters. Several predefined column types are available as shown
in Table IV. There are two kinds of glue types. Predefined glue
types are indicated by various punctuation marks as shown in
Table V. User defined glue types are indicated by numbers.

The rules for placing these specifiers are as follows: (1) no
two glue specifiers can appear next to each other—they are
not additive and must be separated from each other by at least
one column specifier; (2) zero inter-column spacing will be
assumed between back-to-back column specifiers; (3) because
of rule one, back-to-back numerals will be considered as being
a single glue specified by the numerical value represented by
all the digits; (4) a multiletter column specifier can be accessed
by enclosing the letters within braces (otherwise it would be
interpreted as being several single letter column specifiers).
Because of rule three, braces are not needed around multidigit
glue specifiers; (5) there must be at least one column specifier,
but there is no fixed upper limit of how many columns can be
supported; and (6) for IEEEeqnarray, “+” centering glue


will be assumed at each end of the cols specification if
no column glue is specified there. This results in a centered
structure like eqnarray (the 1000pt minus 1000pt glue on
each side “compresses” as needed from each side of the main
text column to center that which is between). Also, IEEE
eqnarray automatically adds a hidden column for equation
numbers to the right of the last specified column. Currently,
there is no support for equation numbers on the left side.13

B. Defining Column Types

New column types are defined with the


command. The col_id argument contains the name of the
column specifier which should consist only of one or more
letters. A given column specifier, even the predefined ones, can
be redefined at will without warning or error.14 The predef
argument contains the commands that will be inserted before
each cell in the column. The postdef argument contains the
commands that will be inserted after each cell in the column.
For example,


Will define a “g” text column which will place club and
diamond suit symbols on either side of a cell’s contents and
center the respective structure within the cell. e.g.,

Using hfil to control cell alignment allows the user

to override the column alignment on a cell-by-cell basis by
placing the infinitely more stretchable hfill on one or both
sides of a cell’s contents. hfill can even be placed between
items in a cell to force them apart and against the “cell walls.”
The IEEEeqnarray predefined columns are designed to allow
user overrides via hfill whenever possible (even for the
math mode cells).

Please note that TEX will not allow unmatched braces within
the arguments of commands. If braces are needed, such as for
the argument of a command, they will have to be provided
within the cells themselves. For example,


defines a column type named “myp” that will place text within
a 0.5 inch wide parbox which is centered on the cell’s baseline.
Note that because the column type name consists of more than
one letter, it has to be enclosed within an extra set of braces
in the column specifications or else it would be interpreted as
three adjacent columns “m”, “y” and “p”. Also, the contents
of the cell must be enclosed within braces so that (1) the par
box command sees the entire contents as its argument; and (2)
the newline within the parbox will not be interpreted as being

13This is not to say that its impossible with the existing capability, just

14Thus allowing new predefined column types to be added without breaking
existing code.

the end of the alignment row. Be aware that it can happen that
a column is given an empty cell, such as in the second row in
the example, or when entering blank separator rows. When this
happens, a relax will appear in the column which will be
acquired as the command’s argument. Therefore, commands
in column definitions that acquire arguments from the cells
should not choke if fed relax.

For reference, the definitions of the predefined column types
are shown here:

% math
% text
% vertical rules
IEEEeqnarraydefcol{v}{}{vrule widtharrayrulewidth}
IEEEeqnarraydefcol{vv}{vrule widtharrayrulewidthhfil}{h
filvrule widtharrayrulewidth}
IEEEeqnarraydefcol{V}{}{vrule widtharrayrulewidthhskipd
oublerulesepvrule widtharrayrulewidth}
IEEEeqnarraydefcol{VV}{vrule widtharrayrulewidthhskipdo
ublerulesepvrule widtharrayrulewidthhfil}%
{hfilvrule widtharrayrulewidthhskipdoublerulesepvrule
% horizontal rules
IEEEeqnarraydefcol{h}{}{leadershrule heightarrayrulewidt
IEEEeqnarraydefcol{H}{}{leadersvbox{hrule widtharrayrul
ewidthvskipdoublerulesephrule widtharrayrulewidth}hfil}
% plain

Note the inclusion of the commands IEEEeqnarraymat
hstyle and IEEEeqnarraytextstyle in the math and
text columns, respectively. These commands allow the user
to control the style of all of the math and text columns.
However, because the changes apply to all the columns, the
user will have to define new column types if different styles
are needed in the same alignment (or different styles can be
manually specified in each cell). The default definitions for
these commands are


which allows the text columns to be in whatever style was in
effect when the alignment was started and the default math
style will be in display style, but can be easily changed as
needed. e.g.,


will result in script style math columns.
The columns relating to vertical and horizontal lines will

be discussed in Appendix F-K as they are typically used only
when producing tables.

The “x” and “X” columns are basic empty text and math
mode columns without any formatting or style controls.

C. Defining Glue Types

New column separation glue types are defined with the



command. The colsep_id argument contains the number of
the column separation glue specifier which should consist only
of numerals. Different glue type names must have different
numerical values. (Don’t get too cute—“007” is identical to
“7”.) User defined column glue specifiers can be redefined
at will without warning or error. The def argument contains
the width of the given glue type. Widths may be specified as
absolute values or reference length commands:

The glue type widths are not evaluated when defined, but are
evaluated each time they are actually referenced as IEEEeq-
narray column specifiers. Thus, for the second definition in
the example above, if tabcolsep were to be revised after
the glue type was defined, the revised value would be what is

Rubber lengths are allowed too. The fact that the centering
glue “+” is a known value can be exploited to achieve some
interesting effects. For example,
IEEEeqnarraydefcolsep{17}{200pt minus 200pt}

will produce a column separation glue that is always 1/5 of
the width of the distance from the equation sides to the ends
of the main text columns. And, of course, “+” can be used as
needed to produce groups of equally spaced equations as in
amsmath’s align:

D. A Simple Example of Use

The example in Section IX can be implemented using
IEEEeqnarray via
Z&=&x_1 + x_2 + x_3 + x_4 + x_5 + x_6IEEEnonumber\
&&+:a + b%

As shown in Table IV the “C” column type is a centered math
mode column with empty ords (“{}”) on either side. So, there
is no need to place empty ords around the equal sign. As with
eqnarray, the & separate the column cells and are where
the inter-column separation glue will appear (when nonzero).

Note the presence of the % at the end of the second row.
TEX does not ignore spaces that occur before commands or
& column delimiters, but does ignore those that occur after.
Most LATEX alignment implementations shield the user from
this behavior by removing all spacing previous to &, \ and
end. The IEEEeqnarray family does not do this! So, it is
important to prevent spaces (including implied ones at the end
of lines) from occurring before such commands unless they are
wanted. Suspect this problem if there is an unexplained offset
within a column. In the given example, unwanted spacing is
not an issue because end spacing is ignored in math mode
anyway. However, it would be an issue if the columns used
text mode instead.

Alternatively, one could use a two column form:
Z=&x_1 + x_2 + x_3 + x_4 + x_5 + x_6IEEEnonumber\

&+:a + b%

E. Equation Numbering

Like eqnarray, IEEEeqnarray, has a “star form,” IE
EEeqnarray*, which does not place equation numbers at the
end of each row by default. The default behavior of individual
rows can be overridden by placing the commands IEEEye
snumber or IEEEnonumber as needed in the last column.
IEEEeqnarray also provides IEEEyessubnumber and I
EEEnosubnumber which can be used to enable or disable
a subequation number for the given row. To support this
feature, IEEEtran defines its own IEEEsubequation counter
(reset with changes to equation) and theIEEEsubequati
on command.15

As of version 1.8 of IEEEtran, the star forms IEEEyesn
umber*, IEEEnonumber*, IEEEyessubnumber* and I
EEEnosubnumber* are available which persist across rows
until countermanded by another star command. The behavior
of later individual rows can be selectively overridden with the
use of the non-star forms as needed.

Despite there being four numbering commands, it is useful
to remember that there are only three IEEEeqnarray numbering

1) Display nothing and do not alter the counters (IEEEn

2) Increment the equation counter and display an equation
number without a subequation part (IEEEyesnumber);

3) Increment the subequation counter and display an equa-
tion number with a subequation number (IEEEyessu

IEEEnosubnumber is not really needed and behaves much
like IEEEyesnumber except that the former does not also
enable equation numbering if it isn’t already on (and does not
alter the numbering properties of the current row if equation
numbering is off).

Generally speaking, only one numbering command should
be used per row. In particular, mixing yes and no commands
on a single row could result in unintended operation. However,
a notable exception is the very useful IEEEyesnumberIEE
Eyessubnumber combination which starts a new subequation
sequence. For example,


x1 (8a)
x2 (8b)
x3 (9a)
x4 (9b)

15What is actually displayed is the theIEEEsubequationdis com-


x5 (10)
x6 (11)

The IEEEyesnumber command increments the equation
counter of what would otherwise have been a subequation
row, resets the subequation counter and turns off subequation
numbering. The following IEEEyessubnumber then incre-
ments the subequation counter by one and restores subequation

Note that any labels for (sub)equations must be placed
after any numbering control command(s) because, prior to that
point, the label will reference the equation number that would
have been used if there had not been any numbering control

Please be aware that IEEEeqnarray, like eqnarray,
will, if the equation is long enough, overwrite the equation
number without warning!17 For cases when this happens, users
can insert a IEEEeqnarraynumspace command at the end
of the line (after any IEEEyessubnumber if used) which
will insert a space equal in width to the displayed equation

· · · + x_z IEEEyessubnumberIEEEeqnarraynumspace\

As a result, the entire multiline equation will be slightly shifted
to the left. IEEE often does the same thing in its journals when
confronted by this situation. If an overfull hbox results, the
offending equation line will have to be further divided.

F. Extra Vertical Spacing and Page Breaks

Like eqnarray, IEEEeqnarray’s \ command supports
a star form which inhibits page breaks at the given line as well
as an optional extra vertical spacing argument:

&+:a + b\*[5pt]

Users are reminded from Section IX that amsmath will
configure LATEX to disallow page breaks within multiline
equations—including those made by IEEEeqnarray be-
cause it also honors the value of interdisplaylinepen

Also like eqnarray, IEEEeqnarray normally places
a small amount of extra spacing (as specified by the length
command jot) between lines to “open up” equations as well
as to prevent large symbols from coming to close to the lines
above them.

G. IEEEeqnarraybox

IEEEeqnarray is not suitable for producing structures
such as matrices and tables because it must have exclusive

16Invoking only a IEEEyessubnumber following a normal equation
number line will result in a sequence like 14, 14a. The IEEE does not typically
use normal equation numbers followed by subequations carrying that same
base equation number, but the capability is there if you ever need it. IEEEtran
versions prior to v1.8 differed here in that they automatically advanced the
equation number on the “first” call to IEEEyessubnumber and so did
not have this degree of flexibility.

17This behavior is extremely difficult to avoid if the equation line is to
remain centered irrespective of the width of the equation number—without
even considering the subjective question of how close is too close for any
given case!

access to the main text column and cannot be nested within
other structures. For these applications, the IEEEeqnarray
box command is provided. IEEEeqnarraybox differs from
IEEEeqnarray in the following ways:

1) the entire contents are wrapped within a box and there-
fore, can be nested within other display or alignment
structures (such as equation, IEEEeqnarray or
even another IEEEeqnarraybox). Note that, like all
box structures, page breaks are not allowed between the
rows of an IEEEeqnarraybox;

2) the default glue at the outer ends of the first and last
columns is 0 pt (“-”), not “+” centering glue as with I

3) no automatic (hidden) equation number column is pro-

4) the star form “IEEEeqnarraybox*” turns off the extra
jot vertical spacing after each row;

5) IEEEeqnarrayboxdecl is the global control.
Two subforms are provided: IEEEeqnarrayboxm which

is for use within math modes and is analogous to array;
and IEEEeqnarrayboxt which is for use within text modes
and is analogous to tabular. If called via IEEEeqnarra
ybox the current math/text mode will be auto-detected and
the proper subform will automatically be selected. Therefore,
IEEEeqnarraybox can replace array as well as tabul

The syntax for IEEEeqnarraybox is similar to IEEEeq
narray, but with two additional optional arguments:

The pos argument can be one of t, c, or b to control where the
box will be vertically aligned relative to the current baseline:
t at the top row; c at the center;18 b at the bottom row. The
default is b.

The width argument specifies the width the box. Warning:
if a width is specified, there must be one or more rubber
lengths in the inter-column glue specifiers (such as that of “*”
or “+”) so that the box can be sized as needed. If there is no
such glue, or the glue provided cannot stretch/shrink enough
as needed, the box cannot be sized to width and an underfull
or overfull hbox error will result. If no width argument is
provided, the box will be set to its natural width (and the use
of rubber inter-column glue will not be required).
IEEEeqnarraybox uses the same column and glue type

specifiers/definitions as IEEEeqnarray.

H. Line Spacing in LATEX

Before discussing some of the more advanced aspects of
vertical spacing control in the IEEEeqnarray family, it is im-
portant to review the details of LATEX’s line spacing algorithm.
Normally, baselines are separated by the amount given by the
length command baselineskip. With each change in font
size, baselineskip is reset to the default value for that font

18Centering is actually done along the “math axis” (not exactly on the text
baseline, but quite close to it). Many LATEX users are not aware of this minor


size (multiplied by baselinestretch). Then the value of
baselineskip is saved to the length variable normalbas
elineskip (so that the normal value can be later referenced
even if baselineskip is set to another value by the user).
However, if the top of a line ever gets closer than lineski
plimit to the bottom of the line above it, the use of basel
ineskip will be suspended and lineskip spacing will be
placed between the two lines.19

This system works well for text. However, for mathematics,
whose symbols have a much higher dynamic range of heights
and depths, it is usually better to go ahead and always add an
extra fixed amount of space (jot) as mentioned in Appendix

When the IEEEeqnarray family is loaded, a new length
command is defined, IEEEnormaljot, which stores the
nominal value of jot20, so that this can be always be referred
to even if other values are currently being used.

At the start of IEEEeqnarray/box, but before the local
or global controls, the following initialization takes place:


Thus, baselineskip is set to the normal value for the
current font, jot is restored to its nominal value and the
lineskiplimit system is disabled.21

This system is designed to better facilitate nested IEEEeq-
narraybox structures as well as to help prevent the user from
encountering seemingly uncontrollable spacing behavior (e.g.,
“How do I get rid of that unwanted space?!”).

I. The IEEEeqnarray Strut System

When creating tables, especially tables with vertical rules,
vertical space between the rows of the table is not generally
desirable because such space will suspend the column cell
definitions and “cut across” any vertical rules that may be
present. Yet, there must be a way to keep rows adequately
spaced apart. To solve this problem, the IEEEeqnarray/box
commands provide an integrated system to manage struts22

contained in a hidden column on the right end of each
IEEEeqnarray/box structure.

The struts in each row will be set to a default strut height
and depth. Normally, the default strut height and depth are
initialized to zero, so the struts will effectively not be present.
The user can set the default strut values via the


command which can be placed in a local or global control. The
optional argument is for commands that will be executed prior
to the evaluation of the height and depth arguments. Thus,


19Within IEEEtran.cls, lineskiplimit and lineskip are zero—if
things get too close it is the author’s responsibility to correct the problem
without having IEEEtran.cls second guessing the author’s intent.

20Within IEEEtran.cls, the nominal value of jot is 25% of the baseli-
neskip for the normalsize font.

21As long as rows cannot be of negative height.
22“Struts” are vertical rules of zero width, but of finite height.

will set the default strut height to half the baselineskip used by
the large font size, even if the current baselineskip (and/or font
size) is different. The commands which are executed within the
optional argument are contained within their own environment
so as not to have any effects outside of the IEEEeqnarra
ystrutsize command. For mimicking the action of bas
elineskip, the typically recommended height and depth of
struts is 70% and 30%, respectively, of normalbaselines
kip23. IEEEeqnarraystrutsize will assume these values
if its height and/or depth arguments are left blank. e.g., in the
previous example, the strut depth will be set to 30% of nor
malbaselineskip for the large font size.

There is also a

command which will add to the current default strut values
and can be used much like the extrarowheight parameter
of the array.sty package. Empty arguments are assumed to be
0 pt.
IEEEeqnarraystrutsize and IEEEeqnarraystruts

izeadd can also be used at the end of the last column to alter
the strut size used for a particular row (the default strut values
of the other rows will not be affected).

There is also a

which produces a strut. It can be used whenever a “manual”
strut is needed—even outside the IEEEeqnarray/box en-
vironments. If a height or depth argument is not provided (or
empty) then these will be assumed in the same way as IEEE
eqnarraystrutsize does.

For diagnostic purposes (in order to see if any row objects
exceed the height of the struts), the command IEEEvisibl
estrutstrue can be placed with an IEEEeqnarray/box
or IEEEstrut control to make the struts visible.

When using IEEEeqnarraybox to produce tables that
contain vertical lines, it is usually desirable to shutdown the
baselineskip system and switch over to pure strut spacing.
The following command sequence, placed within a local or
global control, will serve this purpose:

Note the use of “%” to prevent the ends of the lines that end
in braces from being interpreted as unwanted spaces. Because
of the frequent need to call this sequence, the IEEEeqnarray
family provides the IEEEeqnarraystrutmode command
which does the same thing.

J. Overriding Column Types

Within a row, one or more column types can be overridden
by placing the command

23Note that this not the normalsize baselineskip, but the normal baselineskip
for the current font size.


as the very first command in a cell. This command is the
IEEEeqnarray equivalent of multicolumn. The first argu-
ment is the number of columns to override (cutting through
any inter-column glues as needed). The second argument is the
column type specifier to use. The third argument contains the
cell text. The third argument will have to be enclosed within
an extra set of braces if the column type is to acquire it as an
argument—as was done with the “myp” parbox column type
in the example earlier (Appendix F-B).

There is also the IEEEeqnarrayomit command which,
when used as the very first command in a cell, will suspend the
use of the normal column type for that cell. This is somewhat
like a quicker version of IEEEeqnarraymulticol{1}{x}

Users are cautioned not to use commands like these (e.g.,
multicolumn) that are designed for other alignment envi-

K. Predefined Column Types for Rules

Several of the predefined column types produce vertical or
horizontal lines. Note that, in the IEEEeqnarray family, rules
are declared and treated as normal column types—they are not
hidden. Although this approach may increase the number of
columns the user has to keep track of, especially when creating
tables, it does offer a great deal of flexibility by allowing the
user to override, or otherwise manipulate, any column type
(including those that produce rules) at will.

All of the predefined rule column types use the arrayru
lewidth length to determine the line thickness and doubl
erulesep for the spacing of double rules.

The “v” column type produces a vertical rule, “vv” produces
two back-to-back vertical rules which will appear as one
rule of twice the normal thickness. “V” produces a double
vertical rule with doublerulesep spacing between its two
lines. “VV” produces two back-to-back double vertical rules
which will appear to be three vertical rules, the middle one of
which being twice as thick as the other two. It is possible to
“spread apart” the “vv” and “VV” types by placing a spacer
within their columns—thus they can be used to generate two
single, or double, vertical rules whose separation distance is

The “h” and “H” types produce single and double horizontal
rules, respectively. Horizontal rule types are not normally used
in the column specifications, but rather with the IEEEeqna
rraymulticol command in order to draw a horizontal rule
across one or more column(s).

Please be aware that the line commands of other alignment
environments may not work properly within the IEEEeqnarray
family which provides its own ways of doing these types of
things. In particular, cline is totally incompatible—users
should use the IEEEeqnarraymulticol{num_cols}{h}
{} command instead. However, vline and hline should
work—unless another LATEX package redefines them in some

24Those familiar with TEX may be interested to know that TEX’s omit,
span and multispan should work in IEEEeqnarraybox, but not in
IEEEeqnarray because of the need to track column usage with a hidden
counter in the latter.

incompatible way. The IEEEeqnarray family provides its own
version of vline:


that produces a vertical rule extending from the top to bottom
of a cell without overriding the column type. The optional
argument is for specifying the rule thickness which defaults
to arrayrulewidth if no argument is provided.

The IEEEeqnarray row commands (discussed in the next
section) provide some alternatives to hline.

L. Row Commands

The IEEEeqnarray family has several commands which can
be used to produce special rows that span all the columns.
Unless otherwise noted, the commands described here must
issued as the very first command in a given row.

To produce a spacer row that relies on the strut system, use


The first argument specifies the height of the strut row, if left
blank or empty, the default value of 0.25normalbaseli
neskip will be assumed. The second optional argument is
for commands which will be executed prior to the evaluation
of the first argument as is done with IEEEeqnarraystrut
size. IEEEeqnarrayseprow will not interrupt the column
definitions, so it will not cut vertical lines. If column definition
suspension is desired, use the cutting form which will override
all the column types in the entire row:


To produce a horizontal rule row, use:


which will override all the column definitions with one that
produces a horizontal rule. If the optional rule thickness is not
specified, the value of arrayrulewidth will be used.

To produce a double rule row, use:


which will produce a rule row, a (noncutting) separation row,
followed by another rule row. If the optional rule thickness is
not specified, the value of arrayrulewidth will be used
when producing each of the two rule rows. If the optional
separation distance is not specified, the value of doubleru
lesep will be used. There is also a cutting form:


which works the same way except that the separation row
will override all the column definitions. (Vertical rule columns
will not appear inside the double rule row produced by this

M. Useful Low Level TEX Commands

Although the use of lower level TEX commands is generally
frowned upon in LATEX, some of them are just too helpful to
phantom{} produces an invisible box with the width,

height and depth of its contents, but the contents themselves


will not appear in the output. There is also the hphantom
{} and vphantom{} forms which retain only the contents’
width, or its height and depth, respectively. As an example,
look carefully at the footnotes at the bottom of Table V. This
table was produced using the IEEEeqnarraybox command.
The footnotes are actually contained within the last two rows
of the table. Note how the left sides of the footnotes line
up, even though the first one has a superscript asterisk for a
footnote symbol. The reason that the second row lines up is
because, at its left side, it employs a horizontal phantom of
the very same symbol:


Vertical phantoms can be used to equalize row height or
spacing—such as to get matrices that fit within brackets of
the same size even though one has “tall” symbols and the
other not.

The opposite of hphantom{} is rlap{} which displays
its contents, but with zero width. There is also an llap{}
which does the same thing, but the contained object will appear
just to the left of the given point, rather than after as with
rlap. For example, look closely at the first “Width” column
heading in Table V. The word “Width” is centered irrespective
of the asterisk. That is because the width of the asterisk was


The vertical analog of rlap is smash{} which reduces the
apparent height and depth of its contents to zero. (LATEX’s
raisebox{0pt}[0pt][0pt]{} does about the same thing,
and also provides an adjustable vertical offset.) smash can
be used when space is already reserved for an object, but
that LATEX does not “know” this and would allocate unwanted
additional vertical space. One good use of smash for table
objects that are to be “slipped” into a hidden row of zero
height, or into a row which is to be no higher than the “short”
things, such as horizontal rules, that are in its other columns.

The TEX noalign{} command can be used within IEEEe-
qnarray family to inject text which is outside of the alignment
structure. For example,

noalign{noindent andvspace{jot}}A_3&=&d+2IEEEye


A1 = 7 (12a)
A2 = b + 1 (12b)

A3 = d + 2 (12c)

When employed, noalign must be the very first com-
mand in a row—even before any IEEEeqnarraymulticol,
IEEEeqnarrayomit, or row commands.

Be forewarned that the proper use of noalign can be
tricky. There are three potential issues. (1) Remember that
noalign will place its contents outside of the alignment.

So, the line spacing controls of the IEEEeqnarray commands
will not be in effect. The user may have to manually add bas
elineskip and/or jot spacing as needed (which was done
in the previous example). (2) Furthermore, noalign does
not automatically place its contents within a box. However,
nonaligned material must be placed within a horizontal box
when within the vertical box produced by the IEEEeqnarr
aybox command. Therefore, when using noalign within
a IEEEeqnarraybox, be sure to wrap things up in an

noalign{hbox{and therefore}}

(3) Finally, there may be some issues related to how easily
page breaks occur around the noalign lines. This is an issue
only with IEEEeqnarray because page breaks cannot occur
within the box produced by IEEEeqnarraybox. If needed,
page break desirability can be altered by manually entering
pagebreak, or nopagebreak, etc., at the end of the no
align contents.

N. More Practical Examples of Use

The use of the IEEEeqnarray is somewhat complicated.
However, once the building blocks and core concepts are
understood, the user may find that is easier to use the
IEEEeqnarray family for just about every alignment situation
rather than to have to remember all the interfaces and unique
behaviors of many different tools.

A few “real world” examples will now be demonstrated.
1) IEEEeqnarray Cases Structures: Cases structures can be

obtained using IEEEeqnarraybox:

|x| =
x, for x ≥ 0
−x, for x < 0


which was produced using the code:

x,&for $x geq 0$\
-x,&for $x < 0$%

Note the use of the large quad (1 em) spacing before the
conditional statements. The zeroing of nulldelimiterspa
ce, an optional step, eliminates the width of the nonvisible
closing brace “right.” in order to perfectly center the
visible portion of the equation.26

Note that both branches share a common equation number.
If an equation (sub)number is wanted for each branch, the
preferred solution is to use the cases.sty package as discussed
in Section IX-A. However, it is possible to use IEEEeqnar
ray to build such a thing—although it takes extra work and
a few tricks to do so. For example,

x, for x ≥ 0 (14a)
|x| =

−x, for x < 0 (14b)

25LATEX’s mbox will not work!
26The width of null delimiters is typically only 1.2 pt, and so can usually

be safely ignored.


was produced using the code:

&x,&for $x geq 0$IEEEyesnumberIEEEyessubnumber\*
&-x,&for $x < 0$IEEEyessubnumber

A hidden middle row is used to hold the left hand side of
the equality. In order to prevent this row from altering the
spacing between the two branches, its height must be smashed
and the extra line spacing (which consists of baselinesk
ip, plus jot which is normally 0.25baselineskip for
IEEEtran.cls.) must be removed, half from above and half
from below,—making it look as though the middle row never
occurred. Because the large brace cannot “see” the height of
the branches, it must be manually sized with a strut. The
star form of the new line commands is used to prevent the
possibility of a page break within the structure.

2) Matrices: Displayed matrices can easily be created with

I =

1 0 0
0 1 0
0 0 1


The code of this example is quite simple:

I = left(begin{IEEEeqnarraybox*}[][c]{,c/c/c,}

Because the example matrix has elements of normal height,
one can use the star form of IEEEeqnarraybox to turn off
the extra jot component of the line spacing so as to make
a more compact matrix. If larger symbols had been used in
the matrix, the nonstar form would be the better choice. ar
raycolsep typically serves quite well as an element column
separator. A standard small math space is added to the ends
of the matrix to provide a little distance between it and its
enclosing parentheses.

It is instructive to show how to construct a “small” matrix27,

S =

1/2 0

0 3/4


which was produced via


27IEEE authors should note that the use of small matrices is not recom-
mended as IEEE does not usually reduce font sizes in equations or alter the
main text baselineskip to accommodate in-text mathematics.


Average Delay

λmin λmax

1 0.057 0.172

10 0.124 0.536

100 0.830 0.905*

* limited usability


The use of a user defined command, mysmallarrayde
cl, to contain the IEEEeqnarray setup code, demonstrates
how users can easily recreate their most commonly used
structures by fully exploiting the on-the-fly configurability of
the IEEEeqnarray family.

This example is more complex than need be in order to
demonstrate a few techniques. It would be easy enough to set
baselineskip to the desired value, but suppose that the
matrix rows are to be spaced some multiple of the baselin
eskip of the scriptsize font. Complicating matters even
more is the fact that most LATEX class files will not allow the
user to execute text font size commands within math mode—
and the matrix is within an equation. So, scriptsize cannot
be used to directly set the baselineskip.

The first step is to set the math and text columns to
their desired styles. Then baselinestretch is setup to be
used like arraystretch. The trick is to run scriptsize
within a settowidth command which stores the basel
ineskip of the scriptsize font, multiplied by baseli
nestretch, in normalbaselineskip which is then used
to set baselineskip, jot, etc. Finally, arraycolsep is
reduced to better suit the smaller font. Note the use of “%”
to prevent unwanted spaces from appearing after the braces at
the end of lines in mysmallarraydecl.

3) Tables: Tables, especially those with lines, tend to be a
little more complicated. Table VI was made with the following

caption{Network Delay as a Function of Load}
&&&&IEEEeqnarraymulticol{3}{t}{Average Delay}&\
&1&&& 0.057&& 0.172&\
&10&&& 0.124&& 0.536&\
&100&&& 0.830&& 0.905rlap{textsuperscript{*}}&\



Range Ω(m)

x < 0 Ω(m) =



x ≥ 0 Ω(m) =


ript{*}limited usability}%

Because this table has lines, the first step is to enable strut
mode line spacing. The strut height is then increased by a
couple of points to provide a little more headroom above the
letters.28 This table uses cutting horizontal rules and open
sides as is commonly done in IEEE publications. There are
three extra “x” columns which serve as place holders. The
“x” columns at each end serve as a quick way to get the
horizontal rules to extend a little past the contents of the table.
The middle “x” column serves as an attachment point for the
horizontal rule that is below “Average Delay”. Without this
extra column, the left side of that horizontal rule would cut
into the middle double vertical rule.29 Notice how the “β” is
smuggled in as part of the row containing the horizontal rule.
β has to be smashed so that it will not add unwanted vertical
spacing. Likewise, the strut for that row is disabled. Also, ra
isebox is used instead of smash so that β can be vertically
lowered—otherwise it would appear on its baseline which is
too high for the purpose at hand. The hfill on either side
of β changes the justification of that cell to centered. The
“min” and “max” subscripts would not normally sit at the
same level because the “i” in min is slightly higher than the
letters in “max”. To fix this, a vphantom “i” is added to
“max”. Because these subscripts sit so low, the depth of that
line’s strut is increased a couple of points. Alternatively, one
could have just smashed the “i”. The asterisk next to “0.905”
is reduced to zero width via rlap so that it will not affect its
cell’s width or alignment. This example also illustrates how
to integrate table footnotes into the end of a table without the
help of external packages.

Strut spacing does not work so well for rows that contain
tall symbols because such objects routinely exceed the height
of the struts. Furthermore, increasing the strut height is often
not an option because (1) the height and depth of the tall
symbols must be measured or guessed; and (2) there may be
other rows which have normal line height. Table VII illustrates
such a situation. Its code is shown here:

caption{Possible $Omega$ Functions}

28Knuth calls this extra step a mark of quality.
29Some may even think it would be better that way, but we want to show

some tricks in these examples.

&x < 0&&Omega(m)=sumlimits_{i=0}^{m}K^{-i}&IEEEe
&x ge 0&&Omega(m)=sqrt{m}hfill&IEEEeqnarraystru

The solution is to use IEEEeqnarrayseprow to manually
add in a fixed amount of extra space as needed. In this way,
IEEEeqnarrayseprow can do for lined tables what jot
does for multiline equations. Of course, using this method, the
baselines of the rows will no longer be equally spaced.

The hfill in the square root cell is a cheap, but effective,
way of getting the equal signs to line up without the need of
additional columns.


The author would like to thank Laura Hyslop, Cathy Cardon
and Ken Rawson of the IEEE for their help and support
in making this work possible. The knowledge and prior
work of TEX gurus such as Donald Arseneau, Fred Bartlett,
David Carlisle, Tony Liu, Frank Mittelbach, Piet van Oostrum,
Roland Winkler and Mark Wooding were instrumental in de-
veloping the complex IEEEeqnarray family of commands. The
author is also grateful to Peter Wilson and Donald Arseneau
for allowing the inclusion of their @ifmtarg command.

Finally, this work might not have been possible had it
not been for the efforts of the prior IEEEtran developers:
Gerry Murray, Silvano Balemi, Jon Dixion, Peter Nüchter and
Juergen von Hagen. Their work still lives on to some degree
within IEEEtran.


[1] (2012, Dec.) The IEEE website. [Online]. Available:

[2] M. Shell. (2012, Dec.) The IEEEtran.cls package. [Online]. Available:

[3] ——. (2012, Dec.) IEEEtran homepage. [Online]. Available: http:

[4] H. Kopka and P. W. Daly, Guide to LATEX, 4th ed. Harlow, England:
Addison-Wesley, 2003.

[5] T. Oetiker, H. Partl, I. Hyna, and E. Schlegl. (2011, Apr.)
The not so short introduction to LATEX 2ε. [Online]. Available:

[6] S. M. Moser. (2012, Feb.) How to Typeset Equations in LATEX. [Online].

[7] R. Fairbairns. (2012, Mar.) The TEX FAQ. [Online]. Available:

[8] (2012, Dec.) The IEEE computer society’s conference author
guidelines. [Online]. Available:

[9] S. Pakin. (2009, Apr.) The IEEEconf.cls package. [Online]. Available:

[10] J. D. McCauley, J. Goldberg, and A. Sommerfeldt. (2011, Dec.)
The endfloat.sty package. [Online]. Available:

[11] H. Oberdiek. (2012, May) The ifpdf.sty package. [Online]. Available:


[12] A. Gefen, “Simulations of foot stability during gait characteristic of
ankle dorsiflexor weakness in the elderly,” IEEE Trans. Neural Syst.
Rehab. Eng., vol. 9, no. 4, pp. 333–337, Dec. 2001.

[13] D. Arseneau. (2010, Sep.) The cite.sty package. [Online]. Available:

[14] (2004, Sep.) The amsmath.sty package. The American Mathematical
Society. [Online]. Available:

[15] M. D. Wooding. (1999, Mar.) The MDW tools package. [Online]. Avail-

[16] D. Arseneau. (2010, Feb.) The cases.sty package. [Online]. Available:

[17] S. Tolušis. (2012, Oct.) The stfloats.sty package. [Online]. Available:

[18] D. Carlisle. (2009, Sep.) Packages in the ‘graphics’ bundle.
grfguide.pdf or [Online]. Available:

[19] K. Reckdahl. (2006, Jan.) Using imported graphics in LATEX 2ε.
[Online]. Available:

[20] C. Barratt, M. C. Grant, and D. Carlisle. (1998, May) The psfrag.sty
package. [Online]. Available:

[21] S. D. Cochran. (2005, Apr.) The subfigure.sty package.
[Online]. Available:

[22] ——. (2005, Jul.) The subfig.sty package. [Online]. Available:

[23] A. Sommerfeldt. (2012, Mar.) The subcaption.sty package. [Online].

[24] P. Williams and R. Brito. (2009, Aug.) The algorithmic.sty package.
Also, see the algorithms package homepage:
index.html. [Online]. Available:

[25] S. János. (2005, Apr.) The algorithmicx.sty package. [Online]. Available:

[26] F. Mittelbach and D. Carlisle. (2009, Sep.) The array.sty
package. [Online]. Available:

[27] D. Arseneau. (2003, Jul.) The threeparttable.sty package. [On-
line]. Available:

[28] D. Carlisle. (1999, Apr.) The fix2col.sty package. [Online]. Available:

[29] M. Høgholm. (2003, Dec.) The dblfloatfix.sty package. [Online]. Avail-

[30] M. Shell. (2008, Sep.) The IEEEtran BIBTEX style. [Online]. Available:

[31] P. W. Daly. (2001, Mar.) The balance.sty package. [Online]. Available:

[32] S. Tolušis. (2012, Oct.) The flushend.sty package. [Online]. Available:

[33] M. Shell. (2007, Jan.) The testflow diagnostic suite. [Online]. Available:

[34] T. Oetiker. (2012, Oct.) The acronym package. [Online]. Available:

[35] D. Arseneau. (2007, Jul.) The url.sty package. [Online]. Available:

[36] M. Shell. (2012, Dec.) The IEEEtrantools.sty package. [On-
line]. Available:

[37] C. Schenk. (2012, Dec.) MiKTEX. [Online]. Available: http://www.

Michael Shell (M’87) received the B.E.E., M.S.E.E.
and Ph.D. degrees in electrical engineering all from
the Georgia Institute of Technology, Atlanta, in
1991, 1993 and 2004 respectively. He has developed
several all-optical packet-switched network subsys-
tems and node demonstrations. His research interests
include all-optical packet-switched networks, high
speed opto-electronic interface design, discrete sim-
ulation and exact Markov models for buffered packet

Dr. Shell is also the author of the most recent
versions of the IEEEtran LATEX class and BIBTEX style packages and is the
current maintainer of both.

  • I Introduction
  • II Class Options
    • II-A 9pt, 10pt, 11pt, 12pt
    • II-B draft, draftcls, draftclsnofoot, final
    • II-C conference, journal, technote, peerreview, peerreviewca
      • II-C1 Conference Mode Details
    • II-D compsoc, transmag
      • II-D1 Compsoc Mode
      • II-D2 Transmag Mode
    • II-E letterpaper, a4paper
    • II-F oneside, twoside
    • II-G onecolumn, twocolumn
    • II-H romanappendices
    • II-I captionsoff
    • II-J nofonttune
  • IV The Title Page
    • IV-A Paper Title
    • IV-B Author Names
      • IV-B1 Names in Journal/Technote Mode
      • IV-B2 Names in Conference Mode
      • IV-B3 Names in Compsoc Journal Mode
      • IV-B4 Names in Compsoc Conference Mode
      • IV-B5 Names in Transmag Journal Mode
    • IV-C Running Headings
    • IV-D Publication ID Marks
    • IV-E Special Paper Notices
  • V Abstract and Index Terms
  • VI Sections
    • VI-A Initial Drop Cap Letter
  • VII Citations
  • VIII Equations
  • IX Multi-line Equations
    • IX-A Cases Structures
  • X Floating Structures
    • X-A Figures
      • X-A1 Subfigures
    • X-B Algorithms
    • X-C Tables
      • X-C1 Footnotes Within Tables
    • X-D Double Column Floats
      • X-D1 Double Column Equations
  • XI Lists
    • XI-A Itemize
    • XI-B Enumerate
    • XI-C Description
  • XII Theorems and Proofs
    • XII-A Proofs
  • XIII End Sections
    • XIII-A Appendices
    • XIII-B Acknowledgements
    • XIII-C Bibliographies
    • XIII-D Biographies
  • XIV Last Page Column Equalization
  • Appendix A: Installing IEEEtran
  • Appendix B: PostScript/PDF Output
  • Appendix C: Other Useful or Related External Packages
    • C-A The acronym.sty Package
    • C-B The url.sty Package
    • C-C The IEEEtrantools Package
  • Appendix D: Common User Mistakes
  • Appendix E: Known Issues
  • Appendix F: The IEEEeqnarray Commands
    • F-A IEEEeqnarray
    • F-B Defining Column Types
    • F-C Defining Glue Types
    • F-D A Simple Example of Use
    • F-E Equation Numbering
    • F-F Extra Vertical Spacing and Page Breaks
    • F-G IEEEeqnarraybox
    • F-H Line Spacing in LaTeX
    • F-I The IEEEeqnarray Strut System
    • F-J Overriding Column Types
    • F-K Predefined Column Types for Rules
    • F-L Row Commands
    • F-M Useful Low Level TeX Commands
    • F-N More Practical Examples of Use
      • F-N1 IEEEeqnarray Cases Structures
      • F-N2 Matrices
      • F-N3 Tables
  • Acknowledgment
  • References
  • Biographies
    • Michael Shell