EXHIBIT 1014:
`
`ISO 11898:1993
`
`
`
`
`
`TRW Automotive U.S. LLC: EXHIBIT 1014
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NUMBER 8,513,590
`Case No. IPR2014-01351
`
`

`
`iNTERNAT|ONAL
`
`STANDARD
`
`ISO
`
`11898
`
`First edition
`1993-1 1-15
`
`Road vehicles — Interchange of digital
`information — Controller area network
`
`(CAN) for high-speed communication
`
`Véhicules routiers — Echange d‘information numérique — Gestionnaire
`de réseau de communication a vitesse élevée (CAN)
`
`
`
`T .—
`
`Reference number
`ISO 11898:1993(E)
`
`1014-001
`
`
`
`1014-001
`
`

`
`ISO 11898:1993(E)
`
`Contents
`
`Page
`
`1 Scope
`
`2 Normative references
`
`3 Definitions and abbreviations
`
`3.1 Data link layer definitions
`
`3.2
`
`Physical layer definitions
`
`3.3
`
`List of abbreviations
`
`4 Basic concepts of CAN
`
`4.1
`
`Frames
`
`4.2 Bus access method
`
`4.3
`
`Information routing
`
`4.4 System flexibility
`
`4.5 Data consistency
`
`4.6 Remote data request
`
`4.7
`
`Error detection
`
`4.8 Error signalling and recovery time
`
`4.9 Acknowledgement
`
`4.10 Automatic retransmission
`
`..... ..
`
`4.11
`
`Fault confinement
`
`4.12
`
`"error-active"
`
`4.13
`
`"error-passive"
`
`4.14
`
`"bus off"
`
`5 Layered architecture of CAN
`
`5.1 Reference to OSI model
`
`5.2
`
`Protocol specification
`
`5.3 Format description of services
`
`0 ISO 1993
`All rights reserved. No part of this publication may be reproduced or utilized in any fonn or
`by any means, electronic or mechanical, including photocopying and microfilm, without per-
`mission in writing from the publisher.
`international Organization for Standardization
`Case Postale 56 I CH-1211 Geneve 20 0 Switzerland
`Printed in Switzerland
`
`ii
`
`1014-002
`
`1014-002
`
`

`
`ISO 11898:1993(Ei
`
`5.4
`
`LLC interface
`
`........................................................................ .. 9
`
`6 Description of LLC sublayer
`
`.................................................... .. 9
`
`6.1
`
`Services of LLC sublayer
`
`.................................................... ..
`
`10
`
`6.2 Structure of LLC frames
`
`..................................................... ..
`
`13
`
`6.3
`
`Functions of LLC sublayer
`
`.................................................. .. 15
`
`7
`
`Interface between LLC and MAC
`
`......................................... .. 15
`
`8 Description of MAC sublayer
`
`................................................ .. 16
`
`8.1 MAC sublayer
`
`..........................................................
`
`........ .. 16
`
`8.2 Services of MAC sublayer
`
`.................................................. .. 16
`
`3.3
`
`Functional model of MAC sublayer architecture
`
`21
`
`8.4 Structure of MAC frames
`
`................................................... .. 22
`
`8.5 Frame coding
`
`...................................................................... _. 27
`
`8.6 Order of bit transmission
`
`................................................... .. 27
`
`8.1 Frame validation
`
`................................................................. .. 21
`
`8.8 Medium access method
`
`..................................................... .. 28
`
`8.9 Error detection
`
`.................................................................... .. 29
`
`8.10
`
`Error signalling
`
`.................................................................. .. 29
`
`8.11 Overload signalling
`
`........................................................... .. 29
`
`9
`
`LLC and MAC sublayer conformance
`
`................................... .. 30
`
`10 Description of physical layer
`
`............................................... .. 30
`
`10.1
`
`Functional model of physical layer
`
`................................... .. 30
`
`10.2 Services of physical layer
`
`................................................. .. 31
`
`10.3
`
`Physical Signalling (PLS) sublayer specification
`
`............... .. 31
`
`10.4
`
`PLS—PMA interface specification
`
`...................................... .. 34
`
`10.5 Description of High-Speed Medium Access Unit (HS-MAU)
`
`35
`
`11 Description ofsuperviscr-‘~§ .................................................... .. 50
`
`11.1
`
`Fault confinement
`
`.. ..
`
`,
`
`so
`
`11.2 Bus failure management
`
`.................................................. .. 56
`
`1014-003
`
`1014-003
`
`

`
`ISO 1 1898:1993(E)
`
`Foreword
`
`ISO lthe International Organization for Standardization) is a worldwide
`federation of national standards bodies (ISO member bodies). The work
`of preparing International Standards is normally carried out through ISO
`technical committees. Each member body interested in a subject for
`which a technical committee has been established has the right to be
`represented on that committee. International organizations. governmental
`and non-governmental, in liaison with ISO, also take part in the work. ISO
`collaborates closely with the International Electrotechnical Commission
`(IEC) on all matters of electrotechnical standardization.
`
`Draft International Standards adopted by the technical committees are
`circulated to the member bodies for voting. Publication as an International
`Standard requires approval by at least 75 % of the member bodies casting
`a vote.
`
`International Standard ISO 11898 was prepared by Technical Committee
`ISO/TC 22, Road vehicles, Sub-Committee SC 3, Electrical and electronic
`equipment.
`
`Re1),.a(;;;ce(I uruler license by
`% SAI GLOBAL
`{K J‘ fit/1!! J’-5'lv‘J'.*‘lr"!:‘
`Forest Road Office Centre
`. 4-13
`1:, St 103
`glopfiiigfius N335 07652
`
`1014-004
`
`1014-004
`
`

`
`
`
`ISO 11898:1993(E)
`INTERNATIONAL STANDARD
`
`
`Road vehicles — Interchange of digital information —
`Controller area network (CAN) for high-speed
`communication
`
`1 Scope
`
`This International Standard specifies characteristics of setting up an interchange of digital information between
`Electronic Control Units (ECUS) of road vehicles equipped with the Controller Area Network at transmission rates
`above 125 kbit/s up to 1 Mbit/s.
`
`The Controller Area Network (CAN) is a serial communication protocol which supports distributed real—time control
`and multiplexing.
`
`This specification of CAN describes the general architecture of CAN in terms of hierarchical layers according to the
`ISO reference model for Open Systems Interconnection (OSI) specified in ISO 7498. The data link layer and
`physical layer are specified according to ISO 8802-2 and ISO 8802-3. This International Standard contains detailed
`specifications of aspects of CAN belonging to the
`
`a) physical layer;
`
`bl Qlata link layer
`
`— Logical Link Control (LLC) sublayer,
`
`— Medium Access Control (MAC) sublayer,
`
`All other layers of the OSI model do not have counterparts within this specification of CAN protocol but are part
`of the user's level.
`
`2 Normative references
`
`The following standards contain provisions which. through reference in this text, constitute provisions of this part
`of ISO 1_189B. At the time of publication. the editions indicated were valid. All standards are subject to revision.
`and parties to agreements based on this part of lSO 11898 are encouraged to investigate the possibility of applying
`the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently
`valid international Standards.
`
`ISO 7498:1984, information processing systems — Open Systems Interconnection — Basic Reference Model.
`
`ISO 7637—3:—‘l, Flo-ad vehicles — Electrical disturbance by conduction and coupling — Part 3: Passenger cars and
`light commercial vehicles with nominal 12 V supply voltage and commercial vehicles with 24 V supply voltage —
`Eiectncal transient transmission by capacitive and inductive coupling via lines other than supply lines.
`
`ISO 8802-21989, Information processing systems — Local area networks —— Part 2: Logical link control.
`
`
`1) To be published.
`
`1014-005
`
`1014-005
`
`

`
`ISO 11898:1 993lEl
`
`information technology — Local and metropolitan area networks — Part 3: Carrier sense
`ISO/IEC 8802-321993,
`multiple access with collision detection lCSl\/IA/CD) access method and physical layer specifications.
`
`3 Definitions and abbreviations
`
`For the purposes of this International Standard, the following definitions apply.
`
`3.1 Data link layer definitions
`
`3.1.1 bit rate: Number of bits per time during transmission, independent of bit representation.
`
`3.1.2 bit stuffing: Technique used in bit-oriented protocols in order
`
`— to achieve data transparency (arbitrary bit patterns may not be interpreted as protocol information), and
`
`— to provide "dominant" to "recessive" edges, and vice versa, which are necessary for correct resynchronization
`when using a Non-Retum—to-Zero bit representation.
`
`Whenever the transmitting logic encounters a certain number (stuff width) of consecutive bits of equal value in the
`data, it automatically stuffs a bit of complementary value — a stuff bit -— into the outgoing bit stream. Receivers
`destuff the frame, i.e. the inverse procedure is carried out.
`
`3.1.3 bus: Topology of a communication network, where all nodes are reached by passive links which allow
`transmission in both directions.
`
`3.1.4 bus value: One of two complementary logical values: "dominant" or "recessive". The "dominant" value
`represents the logical
`and the "recessive" represents the logical "1
`During simultaneous transmission of
`"dominant" and “recessive" bits, the resulting bus value will be "dominant".
`
`3.1.5 contention-based arbitration: Carrier Sense Multiple Access (CSMA) arbitration procedure where simul-
`taneous access of multiple nodes results in a contention. One frame will survive the contention uncorrupted.
`
`3.1.6 frame: Data link protocol data unit specifying the arrangement and meaning of bits or bit fields in the se-
`quence of transfer across the transmission medium.
`
`3.1.7 multicast: Addressing where a single frame is addressed to a group of nodes simultaneously. Broadcast
`is a special case of multicast, whereby a single frame is addressed to all nodes simultaneously.
`
`3.1.8 multi-master: System partitioned into several nodes where every node may temporarily control the action
`of other nodes.
`
`3.1.9 node: Any assembly, linked to a communication line, capable of communicating across the network ac-
`cording to a communication protocol specification.
`
`3.1.10 non-return-to-zero: Method of representing binary signals. V\fithin one and the same bit time, the signal
`level does not change, Le. a stream of bits having the same logical value provides no edges.
`
`priority: Attribute to a frame controlling its ranking during arbitration. A high priority increases the proba-
`3.1.11
`bility that a frame wins the arbitration process.
`
`3.1.12 protocol: Formal set of conventions or rules for the exchange of information between nodes, including
`the specification of frame administration, frame transfer and physical layer.
`
`3.1.13
`signals.
`
`receiver: Device that converts physical signals used for transmission back into logical information or data
`
`3.1.14 transmitter: Device that converts information or data signals to electrical or optical signals so that these
`signals can be transferred across ‘the communication medium.
`
`1014-006
`
`1014-006
`
`

`
`ISO 11898:1993(EI
`
`3.2 Physical layer definitions
`
`common mode bus voltage range: Boundary voltage levels of VcAN_._ and VcAN_H, for which proper op-
`3.2.1
`eration is guaranteed if up to the maximum number of ECUs are connected to the bus line.
`
`3.2.2 differential internal capacitance, Cdm (of an ECU): Capacitance seen between CAN_L and CAN_H during
`the recessive state when the ECU is disconnected from the bus line. (See figure 1 .)
`
`3.2.3 differential internal resistance, Rd“, (of an ECU): Resistance which is seen between CAN_L and CAN_H
`during the recessive state when the ECU is disconnected from the bus line. (See figure 1.)
`
`3.2.4 differential voltage, Vdiff: value
`
`Vdiff = VcAN_I-I ‘ VcAN_I.
`
`with the voltages Vc-AN_._ and V¢AN_H denoting the voltages of CAN_L and CAN_H relative to ground of each in-
`dividual ECU.
`
`3.2.5 internal capacitance, C-,,, (of an ECU): Capacitance seen between CAN_L (or CAN_H) and ground during
`the recessive state when the ECU is disconnected from the bus line. (See figure1.)
`
`3.2.6 internal delay time, tECU (of an ECU): Sum of all asynchronous delay times occurring on the transmitting
`and receiving path relative to the bit timing logic unit of the protocol IC of each individual ECU disconnected from
`the bus line.
`
`internal resistance, R“, (of an ECU): Resistance which is seen between CAN_L (or CAN_H) and ground
`3.2.1
`during the recessive state when the ECU is disconnected from the bus line. (See ‘figure 1 .i
`
`3.2.8 physical layer: Electrical circuit realization that connects an ECU to a bus. The total number of ECUs con-
`nected on a bus is limited by electrical loads on the bus line.
`
`3.2.9 physical media (of the bus): Pair of parallel wires, shielded or unshielded, dependent on EMC require-
`ments. The individual wires are designated as CAN_L and CAN_H. The names of the corresponding pins of ECUs
`are also denoted by CAN_L and CAN_H respectively.
`
`I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I
`
`J
`
`CAN_L
`
`CAN_H
`
`II
`‘I
`1II
`
`
`
`
`r___----
`
`3°=
`
`___
`
`-H’
`
`___‘
`
`_
`._
`
`In
`_.
`
`__
`.—
`
`_
`u.
`
`Figure 1 —— Definitions of internal capacitances and internal resistances of ECU
`
`1014-007
`
`1014-007
`
`

`
`ISO 11898:1993(El
`
`3.3 List of abbreviations
`
`ACK
`
`ECU
`
`EOF
`
`CAN
`
`CRC
`
`DLC
`
`IC
`
`FCE
`
`LAN
`
`LLC
`
`Acknowledgement
`
`Electronic Control Unit
`
`End of Frame
`
`Controller Area Network
`
`Cyclic Redundancy Check
`
`Data Length Code
`
`Integrated Circuit
`
`Fault Confinement Entity
`
`Local Area Network
`
`Logical Link Control
`
`LME
`
`LPDU
`
`LSB
`
`Layer Management Entity
`
`LLC Protocol Data Unit
`
`Least Significant Bit
`
`LSDU
`
`LLC Service Data Unit
`
`MAC
`
`MAU
`
`MDl
`
`Medium Access Control
`
`Medium Access Unit
`
`Medium Dependent Interface
`
`MPDU
`
`MAC Protocol Data Unit
`
`MSB
`
`Most Significant Bit
`
`MSDU
`
`MAC Service Data Unit
`
`NR2
`
`OSI
`
`PL
`
`PLS
`
`PMA
`
`RTR
`
`SOF
`
`Non-Return—to—Zero
`
`Open System Interconnection
`
`Physical Layer
`
`Physical Signalling
`
`Physical Medium Attachment
`
`Remote Transmission Request
`
`Start of Frame
`
`4 Basic concepts of CAM
`
`CAN has the following properties:
`
`— multi-master priority-based bus access;
`
`— non-destructive contention—based arbitration;
`
`— multicast frame transfer by acceptance filtering;
`
`— remote data request;
`
`1014-008
`
`1014-008
`
`

`
`ISO 1 1898:1993(E)
`
`_ configuration flexibility.’
`
`- systern-wide data consistency;
`
`— error detection and error signalling;
`
`— automatic retransmission of frames that have lost arbitration or have been destroyed by errors during trans-
`mission:
`
`— distinction between temporary errors and permanent failures of nodes and autonomous switching-off of de-
`fective nodes.
`
`4.1 Frames
`
`Information on the bus is sent in fixed format frames of different but limited length. When the bus is idle, any
`connected node may start to transmit a new frame.
`
`4.2 Bus access method
`
`When the bus is idle, any node may start to transmit a frame. If two or more nodes start to transmit frames at the
`same time, the bus access conflict is resolved by contention—based arbitration using the identifier. The mechanism
`of arbitration guarantees that neither information nor time is lost. The transmitter with the frame of highest priority
`gains bus access.
`
`4.3 Information routing
`
`In CAN systems a node does not make use of any information about the system configuration le.g. node address).
`Instead,
`receivers accept or do not accept
`information based upon a process called "Frame Acceptance
`Filtering", which decides whether the received information is relevant or not. There is no need for receivers to
`know the transmitter of the information and vice versa.
`
`4.4 System flexibility
`
`Nodes may be added to the CAN network without requiring any change in the software or hardware of any node,
`if the added node is not the transmitter of any data frame or if the added node does not require any additional
`transmitted data.
`
`4.5 Date consistency
`
`Within a CAN network it is guaranteed that a frame is simultaneously accepted either by all nodes or by no node.
`Thus data consistency is a property of the system achieved by the concepts of multicast and by error handling.
`
`4.6 Remote data request
`
`By sending a remote frame, a node requiring data may request another node to send the corresponding data
`frame. The data frame and the corresponding remote frame are named by the same identifier.
`
`4.7 Error detection
`
`For dectecting errors, the foltowlng measures are provided:
`
`— monitoring (transmitters compare the bit levels to be transmitted with the bit levels detected on the bus):
`
`— 15-bit cyclic redundancy check;
`
`— variable bit stuffing with a stuff width of 5;
`
`— frame check.
`
`1014-009
`
`1014-009
`
`

`
`ISO 11898:1993(E)
`
`4.8 Error signalling and recovery time
`Corrupted frames are flagged by any transmitting node and any normallly operating (error-active) receiving node.
`Such frames are aborted and will be retransmitted according to the implemented recovery procedure (see 6.3.3).
`The recovery time from detecting an error until the possible start of the next frame is typically 17 to 23 bit times
`(in the case of a heavily disturbed bus. up to 29 bit times). if there are no further errors.
`
`4.9 Acknowledgement
`All receivers check the consistency of the received frame and will acknowledge a consistent frame and flag an
`inconsistent frame.
`
`4.10 Automatic retransmission
`Frames that have lost arbitration and frames that have been disturbed by errors during transmission will be re-
`transmitted automatically when the bus is idle again. A frame that will be retransmitted is handled like any other
`frame. This means that it participates in the arbitration process in order to gain bus access.
`
`4.11 Fault confinement
`CAN nodes are able to distinguish short disturbances from permanent failures. Defective transmitting nodes are
`switched off. "Switched off" means that a node is logically disconnected from the bus line, so that it can neither
`send nor receive any frames.
`
`4.12 "error-active"
`An "error-active" node can normally take part in bus communication and send an active error flag when an error
`has been detected. The active error flag consists of six (6) dominant consecutive bits and violates the rule of bit
`stuffing and all fixed formats appearing in a regular frame (see 11.1.5).
`
`4.13
`"error-passive"
`An "error—passive" node shall not send an active error flag. It takes part in bus communication, but when an error
`has been detected a passive error flag is sent. The passive error flag consists of six (6) recessive consecutive bits.
`After transmission, an "error~passive" node will wait some additional time before initiating a further transmission
`{see suspend transmission in 8.4.5 and 11.1.5}.
`
`4.14 "bus off"
`A node is in the state "bus off” when it is switched off from the bus due to a request of fault confinement entity.
`In the "bus off" state, a node can neither send nor receive any frames. A node can leave the "bus off" state only
`upon 8 U581’ request.
`
`5 Layered architecture of CAN
`
`5.1 Reference to OSI model
`According to the OSI reference model, the CAN architecture represents two layers:
`
`— data link layer,
`
`— physical layer.
`
`1014-010
`
`1014-010
`
`

`
`ISO 1 1898:1993(E)
`
`This International Standard specifies the data link and the physical layer of CAN (see figure 2).
`
`According to ISO 8802-2 and ISO 8802-3 (LAN standards). the data link layer is subdivided into:
`
`— Logic Link Control lLLC);
`
`-— Medium Access Control (MAC).
`
`The physical layer is subdivided into:
`
`— Physical Signalling (PLS);
`
`-— Physical Medium Attachment (PMA);
`
`—— Medium Dependent Interface (MDI).
`supervised by a management entity called the "Fault Confinement Entity
`The MAC sublayer operations are
`checking mechanism that makes it possible to distinguish short disturbances
`lFCE)". Fault confinement is a self-
`from permanent failures (fault confinement: see 11.1).
`The physical layer may be supervised by an entity that detects and manages failures of the physical medium (for
`example, shorted or interrupted bus lines, bus failure management: see 11.2).
`
`Data link layer
`
`LLC
`Acceptance filtering
`Overload notification
`
`Recovery management. nu. . o -4-. nu. -. n a
`
`
`
`
`
`Supervisor
`f“"""""‘"""‘“"
`
`
`
`...-up--__..._......—
`-6 -.— «nu . u. - «-
`
`
`
`
`"M:
`Data encapsulation
`
`/decapsulation
`
`Frame coding
`(stuffing. destuttlng)
`Medium access management
`Err-or defection
`Error signalling
`Acknowledgement
`Serlallzatlon/deserlalizatlon
`
`
`
`
`confinement
`
`
`(MAC—l.MEl
`
`Physical layer
`
`
`
`
`
`
`
`PLS
`Bit encoding/decoding
`Bit timing
`Synchronization
`............................ -....—ou.o--.-nun.»-u
`
`
`
`
`
`
`
`
`Bus failure
`
`- management
`(PLS-LME)
`
`
`
`
`
`
`Driver/receiver characteristics
`
`Connectors
`
`Figure 2 — Layered architecture of CAN
`
`1014-011
`
`1014-011
`
`

`
`ISO 11898:1993(E)
`
`5.2 Protocol specification
`
`Two peer protocol entities communicate with each other by exchanging frame or Protocol Data Units iPDUs). An
`(N)-layer Protocol Data Unit (NPDU) consists of N-layer specific Protocol Control Information (N-PC!) and {N}-user
`data.
`In order to transfer a NPDU it must be passed to a (N-1)—layer entity via a tN-‘il-Service Access Point
`[(N-1)-SAP]. The NPDU is passed by means of the (N-1)-layer Service Date Unit [iN—1i»SDU] to the [N-1l—layer. the
`services of which allow the transfer of the NPDU. The service data unit is the interface data whose identity is
`preserved between {Ni-layer entities. i.e. it represents the logical data unit transferred by a service. The data link
`layer of the CAN protocol does not provide means for mapping one SDU into multiple PDUs nor means for
`mapping multiple SDUs into one PDU, i.e. a NPDU is directly constructed from the associated NSDU and the layer
`specific control information N-PCI. Figure 3 illustrates the data link sublayer interactions.
`
` on -on u- a-— —-—__ nu. :-
`
`Physicul. Layer Interface
`
`Figure 3 — Protocol layer interactions
`
`5.3 Format description of services
`
`5.3.1 Format description of service primitives
`
`Service primitives are written in the form:
`
`service . type (
`[parameter1, .
`)
`
`. .]
`
`"service" indicates the name of the service, eg. L_DATA for data transfer service provided by the LLC sublayer.
`
`"type" indicates the type of the service primitives (see 5.3.2).
`
`"[parameter1,...]" is the list of values passed to the service primitives.
`
`The brackets indicate that this parameter list may be empty.
`
`1014-012
`
`1014-012
`
`

`
`ISO 11898:1993lE)
`
`5.3.2 Types of service primitives
`
`Service primitives are of three generic types:
`
`service. request
`
`The request primitive is passed from the (N)—user (service user) to the (N)-layer (service provider) to request initi-
`ation of the service.
`
`service. indication
`
`The indication primitive is passed from the (N)-layer to the (N)—user to indicate an internal (N)—layer (or sublayer)
`event which is significant to the (N)-user. This event may be logically related to a remote service request, or may
`be caused by an event internal to the (N)—layer (or sublayer).
`
`service. confirm
`
`The confirm primitive is passed from the (N)—|ayer (or sublayer) to the (N)—user to convey the results of one or more
`associated previous service request(s). This primitive may indicate either failure to comply or some level of com-
`pliance. it does not necessarily indicate any activity at the remote peer interface.
`
`5.4 LLC interface
`
`The LLC sublayer offers two types of connectionless transmission services to the LLC user:
`
`— unacknowledged data transfer service.
`
`—— unacknowledged remote data request service.
`
`The interface service data from or to the user is described in 6.1.2. The messages that can be sent between LLC
`user and LLC sublayer are shown in tablet a) and b).
`
`Table 1 — Messages between LLC user and LLC sublayer
`
`
`
`Reset_Request
`
`Request to set the node into an
`initial state
`
`b) Messages sent from LLC sublayer to LLC user
`
`a) Message sent from LLC user to LLC sublayer
`
`
`
`
`
`Response to the
`Reset_Requ est
`
`Indicates the current status of
`the node, i.e. it signals whether
`or not the node is in the state
`"bus off".
`
`
`
`
`
`Fleset_Response
`
`Node_Status
`
`
`
`LLC to user message
`
`Meaning
`
`The LLC interface messages from and to the supervisor fault confinement entity are described in 11.1.3.1.
`
`6 Description of LLC sublayer
`
`The LLC (Logical Link Control) sublayer describes the upper part of the OSI data link layer.
`those protocol issues that are independent of the type of medium access method.
`
`It is concerned with
`
`1014-013
`
`1014-013
`
`

`
`ISO 11898:1993(E1
`
`6.1 Services of LLC sublayer
`
`6.1.1
`
`LLC sublayer
`
`The LLC sublayer offers two types of connectionless-mode transmission sewicesz
`
`Unacknowledged data transfer service
`This service provides means by which LLC users can exchange Link Service Data Units (LSDU) without the es-
`tablishment of a data link connection. The data transfer can be point-to-point, multicast or broadcast.
`
`Unacknowledged remote data request service
`This service provides means by which a LLC user can request another remote node to transmit a Link Service
`Unit (LSDUl without the establishment of a data link connection.
`The wayiin which the remote node serves the data request is not specified here. Basically, there are two ways:
`by the remote user for transmission. In this case the data is located in a re
`al The requested data is prepared
`pon reception of the remote request frame.
`node buffer and will be transmitted by the LLC entity u
`b) The requested data will be transmitted by the remote user upon reception of the remote request frame.
`According to the two different LLC services, there are two types of frames from or to the user:
`
`Data
`
`— LLC Data Frame,
`
`— LLC Remote Frame.
`
`rom a transmitter to a receiver. The LLC remote frame is transmitted to request
`The LLC Data Frame carries data f
`(with the same identifier) from a (single) remote node. In both cases, the LLC
`the transmission of a data frame
`n or reception of a frame to the user.
`sublayer notifies the successful transmissio
`
`6.1.2 Service primitive specification
`This subclause describes in detail the LLC service primitives and their associated parameters. The complete list
`of LLC service primitives is given in table 2.
`
`Table 2 — LLC service primitives overview
`
`Unacknowledged Data Transfer Service
`
`L_Data.request
`
`Request for data transfer
`
`L_Data.indication
`
`Indication of data transfer
`
`Request for remote data request
`
`L_Data.confirm
`
`Confirm data transfer
`
`Unacknowledged Remote Data Request Service
`
`L__Remote.request
`
`L_Remote.indication
`
`lndication of remote data request
`
`L_Flemote.confirm
`
`Confirmation remote data request
`
`10
`
`1014-014
`
`1014-014
`
`

`
`The parameters that are associated with the different LLC service primitives are listed in table 3.
`
`Table 3 — List of LLC service primitive parameters
`
`ISO 11898:1993(E1
`
`
`
`
`
`
`
`
`
`
`
`
`
`6.1 .2.1 L_DATA.request
`
`a) Function
`
`The L_DATA.request primitive is passed from the LLC user to the LLC sublayer to request that a LSDU be sent
`to one or more remote LLC entities.
`
`b) Semantics of L_DATA.request primitive
`
`The primitive shall provide parameters as follows:
`
`L_DATA . request (
`IDENTIFIER
`DLC
`DATA
`)
`
`The parameter DATA is insignificant if the associated LLC data frame is of data length zero.
`
`cl Effect on receipt
`
`Receipt of this primitive causes the LLC sublayer to initiate the transfer of a LLC data frame by use of the data
`transfer service provided by the MAC sublayer (see table 5).
`
`6.1.2.2 L_DATA.indication
`
`a) Function
`
`The L_DATA.indication primitive is passed from the LLC sublayer to the LLC user to indicate the arrival of a
`LSDU.
`
`b) Semantics of L_DATA.indication primitive
`
`The primitive shall provide parameters as follows:
`
`L_DATA . indication (
`IDENTIFIER
`DLC
`DATA
`)
`
`The paramater DATA is insignificant if the associated LLC data frame is of data length zero.
`
`11
`
`1014-015
`
`1014-015
`
`

`
`ISO 11898:1993(E)
`
`cl Effect on receipt
`
`The effect on receipt of this primitive by the LLC user is unspecified.
`
`6.1.2.3 L_DATA.confirm
`
`a) Function
`The l__DATA.confirm primitive is passed from the local LLC sublayer to the LLC user to convey the results of
`the previous L_DATA.request primitive. This primitive is a local confirmation, i.e. it does not imply that the re-
`mote LLC entity or entities have passed the associated indication primitive to the corresponding LLC userlsl.
`
`bl Semantics of L_DATA.confirm primitive
`
`The primitive shall provide parameters as follows:
`
`L_DATA.confirm(
`IDENTIFIER
`TRANSFER_STATUS
`)
`
`The TRANSFEFLSTATUS is used to indicate the completion of the transaction initiated by the previous
`L_DATA.request primitive.
`
`TRANSFER_STATUS;
`
`[COMPLETE,NOT_COMPLETE]
`
`cl Effect on receipt
`
`The effect on receipt of this primitive by the LLC user is unspecified.
`
`6.1 .2.4 L_REMOTE.request
`
`a) Function
`The L_FiEMOTE.request primitive is passed from the LLC user to the LLC sublayer to request a single remote
`LLC entity to transmit a LSDU.
`
`bl Semantics of L_l-'tEMOTE.request primitive
`
`The primitive shall provide parameters as follows:
`
`L_REMOTE.request(
`IDENTIFIER
`DLC
`)
`
`The value of DLC equals the length of the data field of the requested data frame.
`
`0) Effect on receipt
`Receipt of this primitive causes the LLC sublayer to initiate the transfer of an LSDU by use of the remote data
`transfer service provided by the MAC sublayer (see table 5).
`
`12
`
`1014-016
`
`1014-016
`
`

`
`ISO 1 1 898:1993(E)
`
`6.1.2.5 l.._REMOTE.|ndlcatlon
`
`a) Function
`
`The L_REMOTE.indication primitive is passed from the LLC sublayer to the LLC user to indicate the arrival of
`a request for transmission of a LSDU.
`
`bl Semantics of L_REMOTE.'tndication primitive
`
`The primitive shall provide parameters as follows:
`
`L_REMO'I‘E . indication (
`IDENTIFIER
`DLC
`)
`
`The identifier identifies the LSDU to be sent. The value of DLC equals the length of the data field of the re-
`quested data frame.
`
`c) Effect on receipt
`
`The effect on receipt of this primitive by the LLC user is unspecified.
`
`6.1 .2.6 L_REMOTE.confirm
`
`a) Function
`
`The L_REMOTE.confirm primitive is passed from the local LLC sublayer to the LLC user to convey the results
`of the previous L__REMOTE.request primitive. This primitive‘ is a local confirmation, i.e. it does not imply that
`the remote LLC entity has passed the associated indication primitive to the corresponding LLC user.
`
`bl Semantics of L_REMOTE.confirm primitive
`
`The primitive shall provide parameters as follows:
`
`L_REMOTE . confirm(
`IDENTIFIER
`TRANSFER_STATUS
`J
`
`The TRANSFEFi_STATlJS is used to indicate the completion of the transaction initiated by the previous
`L_REMOTE.request primitive.
`
`TRANSFER_STATUS:
`
`[COMPLETE,NOT_COMPLETE]
`
`cl Effect on receipt
`
`The effect on receipt of this primitive by the LLC user is unspecified.
`
`6.2 Structure of LLC frames
`
`LLC frames are the data units that are exchanged between peer LLC entities lLPDU). The structure and format
`of the LLC data and remote frame are specified subsequently.
`
`13
`
`1014-017
`
`1014-017
`
`

`
`ISO 11898:1993lE)
`
`6.2.1 Specification of LLC data frame
`
`A LLC data frame is composed of three bit fields (see figure 4):
`
`— ldentifier field,
`
`— Data Length Code (DLC) field,
`
`— LLC data field.
`
`lclentlfler
`field
`
`DLC
`field
`
`LLC data
`field
`
`Figure 4 — LLC data frame
`
`Identifier
`
`The identifier's length is 11 bits. The most significant bits (ID-10 to lD-4) shall not all be "1
`
`DLC field
`
`The number of bytes in the data field is indicated by the Data Length Code. This Data Length Code consists of
`4 bits. The data field can be of length zero. The admissible number of data bytes for a data frame ranges from 0
`to 8. Values other than those specified in table4 may not be used.
`
`Table 4 — Coding of the numbers of data bytes by the
`Data Length code
`
`Number of data
`bytes
`
`Data Length Code
`
`Data field
`
`The data field consists of the data to be transferred within a data frame. It can contain from 0 bytes to 8 bytes,
`and each byte contains 8 bits.
`
`14
`
`1014-018
`
`1014-018
`
`

`
`ISO 11898:1 993(5)
`
`6.2.2 Specification of LLC remote frame
`
`A LLC remote frame is composed of two bit fields (see figure 5):
`
`— Identifier field,
`
`— DLC field.
`
`Identifier
`field
`
`DLC
`field
`
`Figure 5 — LLC remote frame
`
`The format of the LLC remote frame identifier is identical to the fonnat of the LLC data frame identifier (see
`6.2.1). There is no data field, independent of the value of the data length code. This value is the data length code
`of the corresponding data frame.
`
`6.3 Functions of LLC sublayer
`
`The LLC sublayer provides the following functions:
`
`a)
`
`frame acceptance filtering,
`
`b) overload notification,
`
`c)
`
`recovery management.
`
`6.3.1 Frame acceptance filtering
`
`A frame transaction initiated at the LLC sublayer is a single, self-contained operation independent of previous
`frame transactions. The content of a frame is named by its identifier. The identifier does not indicate the destina-
`tion of the frame b