Supplementary Service is a set of services that modifies or compensate (supplement) the basic telecommunication services. It is a little bit difficult to define it clearly in a few words since the spectrum of the services are so wide. If you look into each of those services, you would gradually absorb the meaning of those services. (Don't try to memorize them.. just try to dig into each services one by one as you come across). For the details, refer to following 3GPP specification as framework

• 22.004 General on supplementary services
• 24.010 Supplementary Services Specification - General Aspects
• 24.080 Mobile radio interface layer 3 supplementary services specification; Formats and coding
• 24.090 Unstructured Supplementary Service Data (USSD); Stage 3

In terms of RRC/NAS protocol, it is very similar to SMS. Like SMS, it is using control channel to carry the data. In WCDMA, it use DCCH to carry the data and in GSM it use SDCCH to carry the data.

The three sections below follow that order. The first shows when the UE can send an SS message. The second shows the three messages and how one transaction runs. The third shows how the operation code inside those messages selects the actual service.

• Channel Requirement
• Major SS Messages
• Operation Code
• Reference

Channel Requirement

As I mentioned above, SS messages is carried by an RRC message which is mapped onto DL/UL DCCH (in case of WCDMA) and SDCCH(in case of GSM). So to perform a Supplementary Service, UE should be in a states where necessary channels are established.

For example, in case of WCDMA, we can perform a Supplementary Service anywhere in between RRC Connection Setup Complete and RRC Connection Release. Exactly when to initiate this service is completely up UE and network implementation.

Let's be more precise about what "necessary channels" means. 24.010 splits SS procedures into two kinds. A call related procedure modifies an ongoing call, for example hold or multiparty. A call independent procedure has nothing to do with a call, for example the registration of call forwarding or a USSD string. The two kinds use the radio connection differently.

A call independent procedure needs its own MM connection. The UE first sends CM SERVICE REQUEST with the CM service type "Supplementary service activation". After the MM connection is up, the REGISTER message is the first CM message on it. At the end, the side that closes the transaction sends RELEASE COMPLETE, and both sides release the MM connection locally. So the RRC connection has to exist, but the SS transaction starts only after the MM connection is set up.

A call related procedure uses the connection of the call. The Facility IE then travels inside call control messages of 24.008, such as SETUP, ALERTING or CONNECT, or inside a FACILITY message with the transaction identifier of the call. Hold and retrieve are special. They use their own call control messages, HOLD and RETRIEVE, instead of the Facility IE. In UMTS, integrity protection is mandatory for all SS signalling, so the security mode command has to come first in both cases.

• Call independent SS starts with CM SERVICE REQUEST : The service type "Supplementary service activation" tells the MSC that a REGISTER will follow.
• Call related SS rides on the call : It needs no new MM connection, and its messages carry the transaction identifier of the call.
• DCCH or SDCCH is only the bearer : Which channel carries the message is a matter of the RRC state, and it does not depend on the service.

Major SS Messages

In terms of messages, Supplimentary Services are made up of following three component messages. Each message opens, continues or closes one transaction, and the actual service request travels inside it in the Facility IE.

• Register
• Facility
• Release Complete

These three messages are the messages of 24.080 for call independent SS. They all use protocol discriminator 1011, which is 0xB. The table below lists their message types and the role each one plays in a transaction.

Bits 8 and 7 of the message type are the send sequence number in messages from the UE, and 0 in messages from the network. So the same REGISTER can appear as 0x3B, 0x7B, 0xBB or 0xFB in an uplink log. The diagram below shows the simplest transaction, one operation started by the UE.

Figure 1. A UE initiated call independent SS transaction. The REGISTER opens the transaction, and the answer to the operation usually arrives in the RELEASE COMPLETE that closes it.

24.010 shows the network answering with one of three components in the RELEASE COMPLETE. A Return result carries the outcome of the operation. A Return error says that the operation failed, for example because the service is not subscribed. A Reject says that the component itself was wrong. A FACILITY message appears only when the transaction needs more than one exchange, as in a USSD dialogue. Either side may also send RELEASE COMPLETE without a Facility IE to close a transaction that is stuck.

• REGISTER is not a registration : The name only means that the message opens a transaction. The operation inside it may be an interrogation, an activation or a USSD request.
• The transaction identifier ties the messages together : The invoke ID inside the Facility IE ties each answer to its operation.
• Check the component type first : Return result, Return error and Reject tell you the outcome before you decode any parameter.

Operation Code

How to implement such a wide variaties of services using only a couple of messages ? Secret lies in Operation code in 'Register' message. Register message contains 'Facility' IE in it and within the IE lies 'operationCode'. Depending on the value of operationCode, different type of Supplementary Service will be performed.

The screenshot below is a decoded Facility IE from a test equipment. Its tree shows the invoke component, the component IDs and the operation code with its parameters. The callouts mark the operationCode field and its value.

The operation code decides how the rest of the component is decoded, so a decoder shows the parameters under the operation name.

• invoke : The component type. 24.080 codes it with tag 0xA1. Return result is 0xA2, Return error 0xA3 and Reject 0xA4.
• invokeID and linkedID : The invoke ID identifies this operation within the transaction. The linked ID is optional, and it is present only when this invoke belongs to an earlier one.
• operationCode : registerSS : This value, marked with the green box, selects the registerSS operation, and the decoder then reads the parameters as its argument.
• registerSS parameters : ss-Code allSS, basicService, forwardedToNumber, forwardedToSubaddress and noReplyConditionTime 5 belong to the argument of registerSS. This operation is imported from MAP, so its argument is defined in 29.002 rather than in 24.080.

operationCode has very long list of elements in it as shown below. It would take pretty long time and a lot of reading to understand the details of each of these parameters. I will explain on each of these parameters as I come accross.. I don't know how long it would take to cover all of these -:)

• registerSS
• eraseSS
• activateSS
• deactivateSS
• interrogateSS
• notifySS
• registerPassword
• getPassword
• processUnstructuredSS-Data
• forwardCheckSS-Indication
• processUnstructuredSS-Request
• unstructuredSS-Request
• unstructuredSS-Notify
• eraseCCEntry
• callDeflection
• userUserService
• accessRegisterCCEntry
• splitMPTY
• retrieveMPTY
• forwardChargeAdvice
• holdMPTY
• buildMPTY
• forwardCUG-Info
• explicitCT
• lcs-LocationNotification
• lcs-MOLR
• lcs-AreaEventRequest
• lcs-AreaEventReport
• lcs-AreaEventCancellation
• lcs-PeriodicLocationRequest
• lcs-LocationUpdate
• lcs-PeriodicLocationCancellation

The list above is older than the current specification. 24.080 v19.3.0 adds the location services operations lcs-PeriodicTriggeredInvoke, lcs-EventReport, lcs-CancelDeferredLocation, lcs-MSCancelDeferredLocation, lcs-LocationPrivacySetting, lcs-PruAssociation, lcs-PruDisassociation, lcs-SLMOLR, lcs-SLMTLR, lcs-DLRSPPTransport and lcs-ULRSPPTransport. The name forwardChargeAdvice is the advice of charge operation.

The operations come from two sources. Twelve of them are imported from MAP, 29.002: registerSS, eraseSS, activateSS, deactivateSS, interrogateSS, registerPassword, getPassword, processUnstructuredSS-Request, unstructuredSS-Request, unstructuredSS-Notify, eraseCC-Entry and forwardCheckSS-Indication. They keep their MAP operation codes. The others are defined in 24.080 itself. The table below gives the local operation codes of those, as the CODE clause of each definition writes them.

The ASN.1 below is the object set that 24.080 lists as the operations the SS protocol supports. It also shows one operation defined in 24.080, with its argument, result, errors and code. Note the timer in the comment. It tells the invoking side how long to wait for the answer.

Following is based on 24.080 v19.3.0 (Release 19)

Supported-SS-Operations OPERATION ::= {forwardCheckSS-Indication | registerSS | eraseSS |
	activateSS | deactivateSS | interrogateSS | registerPassword | getPassword |
	processUnstructuredSS-Request | unstructuredSS-Request | unstructuredSS-Notify | eraseCC-Entry |
	processUnstructuredSS-Data | notifySS | forwardChargeAdvice | buildMPTY | holdMPTY |
	retrieveMPTY | splitMPTY | explicitCT | forwardCUG-Info | accessRegisterCCEntry |
	callDeflection | userUserService | lcs-LocationNotification | lcs-MOLR | lcs-SLMOLR | lcs-AreaEventRequest |
	lcs-AreaEventReport | lcs-AreaEventCancellation | lcs-PeriodicLocationRequest |
	lcs-LocationUpdate | lcs-PeriodicLocationCancellation | lcs-PeriodicTriggeredInvoke |
	lcs-EventReport | lcs-CancelDeferredLocation | lcs-SLMTLR | lcs-DLRSPPTransport | lcs-ULRSPPTransport }

processUnstructuredSS-Data	OPERATION ::= { -- Timer T(PUSSD)= 15s to 30s
	ARGUMENT	SS-UserData
	RESULT	SS-UserData
	-- optional
	ERRORS	{
	systemFailure |
	unexpectedDataValue}
	CODE	local:19 }

• MAP operations keep MAP codes : 24.080 allocates the same local values as MAP, so the MSC can pass these operations through without translation.
• Most 24.080 codes sit between 98 and 127 : The multiparty, charging, deflection and location services operations use this range, while notifySS and processUnstructuredSS-Data keep their low codes.
• The list keeps growing : New location services operations were added long after the basic SS set, so an old decoder may show them as unknown codes.

Reference

• 3GPP TS 24.010 v19.1.0 : Mobile radio interface layer 3; Supplementary services specification; General aspects
• 3GPP TS 24.080 v19.3.0 : Mobile radio interface layer 3 supplementary services specification; Formats and coding
• 3GPP TS 24.008 v20.0.0 : Mobile radio interface Layer 3 specification; Core network protocols; Stage 3