Description
CREF is a specific message type within the Signaling Connection Control Part (SCCP) protocol, which operates at Layer 4 of the SS7/C7 signaling stack. It is generated as a negative response to an SCCP Connection Request (CR) message. When a network node (e.g., a Mobile Switching Center - MSC) sends a CR to establish a signaling connection with another node (e.g., a Home Location Register - HLR), the receiving node may reject the request for various reasons. Upon such a decision, the receiving node formulates and transmits a CREF message back to the originator. This message contains mandatory parameters, most importantly the Destination Local Reference (DLR), which is copied from the Source Local Reference (SLR) of the incoming CR to correlate the response with the specific request. It also includes a mandatory 'Refusal Cause' parameter, which is a critical piece of information indicating the exact reason for the connection refusal, such as 'no translation for an address of such nature', 'network congestion', 'user not reachable', or 'invalid message'. The CREF message terminates the connection establishment procedure for that specific attempt, and the originating node must interpret the cause code to determine its next action, which could involve rerouting the signaling request, applying back-off timers, or notifying higher-layer applications of the failure. The reliable and standardized delivery of this refusal cause is essential for network diagnostics, fault management, and maintaining overall signaling network stability by preventing repeated attempts on unreachable or congested destinations. The protocol procedures ensure that upon sending or receiving a CREF, both nodes clear any temporary resources allocated for that connection attempt.
Purpose & Motivation
The CREF message exists to provide a controlled and informative mechanism for rejecting SCCP connection establishment requests within circuit-switched telecommunication networks. Prior to standardized signaling protocols like SS7, network interconnection and error handling were often proprietary and less efficient. The SCCP protocol, and by extension the CREF message, was created to provide a connection-oriented service on top of the inherently connectionless Message Transfer Part (MTP) of SS7, enabling reliable transaction dialogues for services like mobile roaming and intelligent networking. The CREF message solves the problem of silent failures or ambiguous rejections. Without it, a node sending a CR might simply time out, leaving it uncertain whether the peer was down, congested, or if the message was invalid. By mandating a refusal with a specific cause, CREF allows the originating node to understand the failure reason programmatically. This enables intelligent network behavior, such as selecting an alternative HLR in case of 'user unknown', applying flow control in case of 'network congestion', or logging faults for operator intervention. It is a fundamental element of robust signaling, ensuring that network resources are not tied up awaiting responses from failed connections and that service logic can handle failures gracefully, which is critical for the reliability of telephony and early mobile services.
Key Features
- Defined negative response to an SCCP Connection Request (CR)
- Carries a mandatory 'Refusal Cause' parameter for diagnostic clarity
- Uses Destination Local Reference (DLR) for precise request-response correlation
- Terminates the connection establishment procedure immediately
- Enables network nodes to implement intelligent failure recovery strategies
- Fundamental to the error and congestion control mechanisms of SS7 signaling
Evolution Across Releases
CREF was formally specified as part of the SCCP protocol for GSM/UMTS circuit-switched core networks in 3GPP Release 4. The initial architecture defined it within the SS7-based BSSAP and RANAP signaling for connection-oriented services. Its capabilities included standardized cause codes for refusal, enabling clear error reporting between network entities like the MSC and HLR during procedures like location updating or call setup.
Defining Specifications
| Specification | Title |
|---|---|
| TS 03.071 | 3GPP TR 03.071 |
| TS 25.410 | 3GPP TS 25.410 |