erations and ASPs that are carried by the OvhMessTrain message format. A closer look in EIA553 reveals that there are 5 message types defined within an OvhMessTrain: Spom1, Spom2, Cfm, Rim and Gaom, see the format in Fig. 5.35. The first two message types, Spom1 and Spom2 must always be sent, and may contain an intermediate Cfm message. After Spom2, any mix of Gaom, Rim and Cfm messages may be added (in EIA553 regarded as a "sequence of words"). 5 Protocol Network Modelling Neither of these messages require any response from the MS, and no immediate action is required by the MS. All of the messages only provide the MS with infor- mation about the actual cell and the network. The ASPs that are carried can there- fore be expected to be ASPs of the operation class C_REPORT, comprising a single ReportConfirm primitive per operation. The first thing to be aware of when looking for ASP information in a given mes- sage format is that not all parameters belong to APSs. There will most likely exist parameters that are only handled by the MEH. In that case, they will appear in more than one message type. EIA553 revealed three such parameters: OHD, END and NAWC, see Fig. 5.35. OHD is a message type identifier (MTid), used to distinguish between the five message types that can occur in an OvhMessTrain. NAWC exists in the first message in the train (the Spom1) and tells how long the rest of the message train is. END is a kind of fragment indicated. It exists in message types Spom2, Gaom and RIM, and indicates if the particular message is the last one or not in the OvhMessTrain So far, we have taken care of the message format for the OvhMessTrain, which is quite straightforward. Next, we will take a look at the format of the five message types in order to specify the message format of each message type, and extract ASP information. If the protocol designers had used our message model and designed the abstract protocol before designing message formats, one could expect that only one of the message formats would carry ASPs, and 