Here we will instead focus on the connectivity service. Figure 3.14 is an example of how CON connections can be used. User- User protocol User- User protocol User- contr. contr. contr. Connection endpoint a SAPI b SAPI C SAPI Connection Connection CON-CSP The connectivity structure User-UDT User protocol User-UDT User protocol User-UDT Fig. 3.14 Using CON connections Subflows, identified by CEIs, can be used by a CONU user to associate individ- ual user-data termination units (user-UDT) inside the CONU user to user-UDTs on other SAPs (user-UDTs are example of protocol elements). A CONU can instanti- 3.2 The Communication Service Provider ate as many user-UDTs as the maximum number of connection endpoints that the CON-CSP allows in a CON-SAP. It is important to understand that a CON connection does not represent a perma- nent network service interface, only SAPs and CSIs do. CON connections are logi- cal and temporary associations between subflows in different SAPs. The identification of a subflow in a SAP is the connection endpoint identifier. CEIs are locally defined in a terminal system. The communication between the CONU and the CON-CSP is always over the CON-SAP. Figure 3.15 shows some send events that may occur over a CON-SAP and how receivers are referred in those events. User- controller sendConOrder(x) CEI, d1 SDU) sendConOrder(y CEI, d2 SDU) CON-CSP Fig. 3.15 Sending and receiving over a CON-SAP The model in Fig. 3.15 assumes a user-UDT that uses two CEIs, X and y, in par- allel. The user-UDT is sending the SDU d1, referring X, and another SDU, d2, referring y. The CON-CSP uses the CEI-information to make sure that d1 and d2 are delivered to the proper remote user-UDT. Both SAP and CSI symbols are constructed by combining two port-notations. The concept of a port is very important for all types of connectivity relations. It represents a way for units to use local identifiers to refer to such relations. Thereby, it becomes possible to specify units independently of how the connectiv- ity relation is refer