The relationship between the ACU primitive type and the supplementary service operation that is carried can be divided into the following categories:
Tightly coupled services and primitives require that the supplementary service operation identifier and operation type be associated with a specific ACU primitive. For example, invocation of the advice of charge request supplementary service must always be done within an ACU_CONN_RQ primitive.
When a service is tightly coupled with an ACU primitive, the service description in this document lists the primitive to use. If the application sends the service request in the wrong primitive, the stack returns ACU_OP_TYPE_REJECT with a local cause of ACU_SS_REJECT_LOCAL_INVALID_STATE in response.
Loosely coupled services and primitives share the same connection ID. In other words, the service applies to the same connection as the basic primitive. However, these services can be carried in any type of basic primitive.
When a loosely coupled service structure must be sent over the interface and a basic call control primitive is also being sent, the two can be combined into a single buffer. If there is no basic call primitive, the ACU_FACILITY_RQ/IN/CO primitive can be used as a NULL basic call message and the service structure can be attached to it. For example, invocation of the Advice of Charge Inform service can be carried in any of the basic call primitives (ACU_ALERTING_IN, ACU_CLEAR_IN), or it may be in an ACU_FACILITY_IN.
Even though the primitive and the service are loosely coupled, the call state may prohibit the successful invocation of the service. For example, the explicit call transfer (ECT) service cannot be invoked on an inbound call that has not been answered. However, the service request can be sent in the ACU_CONN_RS primitive or a subsequent ACU_FACILITY_IN primitive.
Most supplementary services are loosely coupled with the primitive that carries them. The application must not assume which primitive type will carry a loosely coupled service.
Connection-independent services are not associated with a call in any way. An example of a connection-independent service is the activate diversion supplementary service.
Because there is no connection number associated with this service, a different mechanism is used to allow the discrimination between connection-oriented and connection-independent signaling. The sapi field is used for this purpose.
The sapi field of a connection-oriented message (for example, ACU_CONN_RQ) is set to ACU_SAPI. The sapi field of a connection-independent message is set to ACU_SAPI_MGT. The ACU_FACILITY_RQ/IN/CO are the only primitives used to carry connection-independent service structures.
When the application constructs a connection-independent service structure, it should attach it to an ACU_FACILITY_RQ and set the value of the sapi field to ACU_SAPI_MGT. The application's discrimination function must not use the connection ID field of the message when the sapi field indicates a connection-independent message.