The SS7 signalling link is responsible for the transmission and error-free delivery of bits of information over a physical communication medium. 

The model of the SS7 signalling link level is presented here to describe concepts that are used throughout the specification of SS7-LPI. It is described in terms of an interface architecture, as well as addressing concepts needed to identify different components of that architecture. The description of the model assumes familiarity with ITU-T Q.700-Series Recommendations. 

Each layer of the SS7 Protocol Stack has two standards: 

SS7-LPI is an implementation of the first type of standard. It specifies an interface to the services of the SS7 Signalling Link level. The following picture depicts the abstract view of SS7-LPI. 

The SS7 Signalling Link interface is the boundary between the Message Transfer Part (MTP) Level 3 (Network) and Message Transfer Part (MTP) Level 2 (Link) levels in the SS7 model. The network level entity is the user of the services of the signalling link interface (SLS user), and the link level entity is the provider of those services (SLS provider). The interface consists of a set of primitives that provide access to the link level services, plust the rules for using those primitives (state transision rules). A signalling link service primitive might request a particular service or indicate a pending event. 

To provide uniformity across various UNIX system networking products, an effort is underway to develop service interfaces that map to the OSI Reference Model. A set of kernel-level interfaces, based on the STREAMS development environment, constitute a major portion of this effort. The services primitives that make up these interfaces are defined as STREAMS messages that are transferred between the user and provider of the service. SS7-LPI is one such kernel-level interface, and is targeted for STREAMS protocol modules that either use or provide SS7 Signalling Link services. In addition, user programs that wish to access a STREAMS-based signalling link provider directly may do so using the putmsg(2) and getmsg(2) system calls. 

Referring to the asbtract view of SS7-LPI (Figure 18), the SLS provider is configured as a STREAMS driver, and the SLS user accesses the provider using open(2) to establish a stream to the SLS provider. The stream acts as a communication endpoint between an SLS user and the SLS provider. After the stream is created, the SLS user and SLS provider communicate via the messages presented later in this section. 

SS7-LPI is intended to free SS7 signalling link users from specific knowledge of the characteristics of the signalling link provider. Specifically, the definition of SS7-LPI hopes to acheive the goal of allowing an SLS user to be implemented independent of a specific communications medium. Any signalling link provider (supporting any communications medium) that conforms to the SS7-LPI specification may be substituted beneath the SLS user to provide the signalling link services. Support of a new SLS provider should not require any changes to the implementation of the SLS user. 

The signalling link provider interface supports only one of the three OSI modes of communications at the data link layer: connection mode. The other two modes (connectionless and acknowledged connectionless) are not supported by SS7. The connection mode is circuit-oriented and enables data to be transferred over a pre-established connection in a sequenced manner. Data may be lost or corrupted in this service mode, however, due to provider-initiated resynchronization or connection aborts. 

Connectionless and acknowledged connectionless modes are provided by the upper levels of the SS7 protocol (i.e., SCCP). 

The connection-mode service is characterized by four phases of communication: local management, connection establishment, data transfer, and connection release. 

This phase enables an SLS user to initalize a stream for use in communication and establish an identity with the SLS provider. 

This phase enables two SLS users to establish a signalling link connection between them to exchange data. One user (the calling SLS user) initiates the connection establishment procedures, while another user (the called SLS user) waits for incoming connect requests. The called SLS user is identified by an address associated with its stream (as will be discussed shortly). 

A called DLS user may either accept or deny a request for a data link connection. If the request is accepted, a connection is established between the SLS users and they enter the data transfer phase. 

For both the calling and called SLS users, only one connection may be established per stream.