The send operator (either "send" or "=") is used in cases where a decoder should be able to accept various inputs but an encoder should send something particular. It is commonly used in relation to padding, such as

-- Padding using L bits:
<spare padding> ::= { <bit> send L }**;

-- A single pad bit, commonly used as <spare bit>**:
<spare bit> ::= <bit> send 0;

We've seen a few uses of the send operator in the 3GPP specifications that were likely not written as intended. There are basically two issues: 1) inattention to operator precedence, and 2) mistakes in planning for extension compatibility. These issues are illustrated in 3GPP 44.018 10.5.2.25c RR Packet Uplink Assignment. We'll discuss each of these here, with simplified examples.

The send operator has the lowest precedence of the operators; this seems to be frequently overlooked. A common pattern of use is this:

{ null | 0 bit** = <no string> | 1 <stuff> }

which is equivalent to

{ { null | 0 bit** } = {<no string> | 1 <stuff> } }

This is clearly wrong (the encoder strings are not all accepted by the decoder string). Most likely, what they really wanted was:

{ null | 0 { bit** = <no string> } | 1 <stuff> }

In the remainder of this discussion, the examples will be corrected for operator precendence.

Next, consider this example:

{ null | 0 { bit** = <no string> }
       | 1 <stuff> 
           { null | 0 { bit** = <no string> }
                  | 1 <more stuff> <spare bit>** }
}                
            

This pattern of usage is meant to allow interoperability between releases. It occurs at the end of an information element that must be a multiple of 8 bits. The context means that we must be able to add padding bits at the end, but the above doesn't allow an encoder to encode padding in all cases (for example, no padding can be encoded if you choose to omit "stuff"). Let's say we correct this as follows:

{ null | 0 { bit** = <no string> }
       | 1 <stuff> 
           { null | 0 { bit** = <no string> }
                  | 1 <more stuff> }
}
<spare bit>**                
            

Now we can always add the necessary pad bits, but what about the bit** = <no string> constructions? On decoding, any bits these constructions could consume could also be consumed by <spare bit>**. On encoding, these constructions don't encode anything and may as well not be there. In short, these constructions are really useless. We therefore further simplify the example to:

{ null | 0 
       | 1 <stuff> 
           { null | 0 
                  | 1 <more stuff> }
}                
<spare bit>**