While data carousels work well enough for a teletext system or for a simple application, it has some major limitations. The biggest of these is the very nature of the data carousel. It basically lets the broadcaster transmit chunks of data over an MPEG-2 connection, but it says nothing about what that data actually is: the application that is reading the data carousel has to know the format of what is contained in the data carousel and how to deal with it. For MHP or OCAP applications, this is a big problem since the file and directory structure is such an important way of organising your files and is needed to distinguish application code from assets. The solution to this is the object carousel.
An individual object carousel is also called a service domain in some documents. To be precise, a service domain is a group of related DSM-CC objects. In broadcast systems, there is no difference between an object carousel and a service domain except for the terminology: an object carousel is a service domain, and vice versa.
Object carousels and data carousels
Object carousels are built on top of the data carousel model, but they extend it to add the concept of files, directories and streams. This allows the carousel to contain a true filesystem – a set of directories and files that contains a directory structure like you would see on a PC. In fact, it goes one better than that – Stream objects allow an object carousel to refer to elementary streams that are part of the broadcast, and Stream Event objects allow a receiver to know about specific synchronization points within a stream.
As well as building on top of the DSM-CC data carousels, object carousels are built on top of the Object Request Broker (ORB) framework that was defined by CORBA. Each object within the object carousel is broadcast as a BIOP (Broadcast Inter-ORB Protocol) message as defined by CORBA, and each message is contained within a DSM-CC data carousel module. We will take a detailed look at the various message types in a moment, but for now it’s enough to know that the following message types can be carried in an object carousel:
- File messages represent real files. They contain the actual data that makes up the file.
- Directory messages represent logical containers for a set of file messages. Each DSM-CC directory contains a number of files (just like directories in a real filesystem), and a DSM-CC directory message contains a set of references to the files that are within that directory.
- Stream messages are references to MPEG-2 streams, often containing video or audio data. Each stream message can either refer to a single MPEG-2 program, or to one or more elementary streams.
- Stream Event messages describe a set of synchronization points (called stream events) that are contained in a stream. The stream events themselves are described by specific descriptors that we will see later, but Stream Event messages tell the receiver what stream events are present in the stream and associate them with a textual name.
- Service Gateway messages represent a concept that is similar to a directory (and in fact Service Gateway messages are almost identical to Directory messages). The main difference is that Service Gateway messages identify the root directory of the object carousel . This means that every object carousel will have one and only one Service Gateway message.
Several BIOP messages can be contained within every data carousel module (the exact number depends on the size of the messages, given the size limitation on data carousel modules). We won’t discuss the detailed format of these messages here: if you want to know more about this, take a look at the DVB Implementation Guidelines For Data Broadcasting (ETSI document number TR 101 202). This provides a detailed but readable overview of the object carousel specification.
BIOP messages in detail
As we have already seen, an object carousel is made up of a series of BIOP messages carried in a DSM-CC data carousel. Different message types represent the different kinds of object that you can find in an object carousel.
All DSM-CC messages contain their payloads within the message itself. For instance, a File message will contain the complete contents of that file. As well as the payload, each DSM-CC message will have some additional fields that describes the message. The first of these fields is always a four-byte magic number. This identifies the start of a BIOP message, and also allows the receiver to easily check whether a given data carousel module is carrying BIOP messages (since a module will always contain a complete BIOP message, any modules containing object carousel data will start with this magic number). The value of this magic number is the ASCII string ‘BIOP’ (0x42494F50 hexadecimal).
From our perspective however, the most useful of these are the version number and the object kind. The version number is a pair of 32-bit values that give a major and minor version number for every object. This is updated whenever a new version of the message is broadcast, and this allows the receiver to load the latest version of a particular message.
Since a BIOP message can contain several different types of data, the objectKind field that identifies the type of data it carries. DSM-CC allows a great deal of flexibility in this, and the value of this field can be much larger than is necessary. DVB defines this value to be a four-byte string, where the first three bytes are an abbreviation describing the data it carries and the final byte provides zero termination. We will examine the values that can be given to this field when we examine each message in turn.
One of the other useful fields (although more useful for object carousel generators than for receivers) is the object key. This is a unique value that identifies the message, and which is used within CORBA Interoperable Object References (IORs), to identify that particular object. There are a number of other common fields, but we won’t examine them in any great detail. More discussion of these is available in the DSM-CC specification if you really need it.
Each BIOP message starts with a header. This header contains the following fields:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| BIOP message header { | ||||
| magic | 32 | uimsbf | 0x42494F50 | "BIOP" |
| biop_version.major | 8 | uimsbf | 0x01 | BIOP major version 1 |
| biop_version.minor | 8 | uimsbf | 0x00 | BIOP minor version 0 |
| byte_order | 8 | uimsbf | 0x00 | big endian byte ordering |
| message_type | 8 | uimsbf | 0x00 | |
| message_size | 32 | uimsbf | * | |
| objectKey_length | 8 | uimsbf | N1 | |
| for (i = 0; i <N1; i++) { | ||||
| objectKey_data_byte | 8 | uimsbf | + | |
| } | ||||
| objectKind_length | 32 | uimsbf | 0x04 | |
| objectKind | 4*8 | uimsbf | ||
| } |
The magic number that is used in the BIOP message header is the ASCII characters for the string ‘BIOP’. The version numbers refer to the version of the BIOP protocol that is being used – for MHP, ACAP, and OCAP, this is fixed as version 1.0 and so the version numbers in the message headers will always be the same.
File messages
File messages have the following format:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| BIOP::FileMessage () { | ||||
| magic | 32 | uimsbf | 0x42494F50 | "BIOP" |
| biop_version.major | 8 | uimsbf | 0x01 | BIOP major version 1 |
| biop_version.minor | 8 | uimsbf | 0x00 | BIOP minor version 0 |
| byte_order | 8 | uimsbf | 0x00 | big endian byte ordering |
| message_type | 8 | uimsbf | 0x00 | |
| message_size | 32 | uimsbf | * | |
| objectKey_length | 8 | uimsbf | N1 | |
| for (i = 0; i <N1; i++) { | ||||
| objectKey_data_byte | 8 | uimsbf | + | |
| } | ||||
| objectKind_length | 32 | uimsbf | 0x00000004 | |
| objectKind_data | 4*8 | uimsbf | 0x66696C00 | "fil" type_id alias |
| objectInfo_length | 16 | uimsbf | N2 | |
| DSM::File::ContentSize | 64 | uimsbf | + | objectInfo |
| for (j = 0; j < N2 – 8; j++) { | ||||
| objecIinfo_data_byte | 8 | uimsbf | + | |
| } | ||||
| serviceContextList_count | 8 | uimsbf | N3 | |
| for (k = 0; k < N3t; k++) { | ||||
| serviceContextList_data_byte | 8 | uimsbf | + | ServiceContext List |
| } | ||||
| messageBody_length | 32 | uimsbf | + | |
| content_length | 32 | uimsbf | N4 | |
| for (l = 0; l < N4; l++) { | ||||
| content_data_byte | 8 | uimsbf | + | actual file content |
| } | ||||
| } |
Directory and Service Gateway messages
BIOP Directory and Service Gateway messages both share the same structure, with some minor differences in the values of some of the fields:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| BIOP::DirectoryMessage { | ||||
| magic | 32 | uimsbf | 0x42494F50 | "BIOP" |
| biop_version.major | 8 | uimsbf | 0x01 | BIOP major version 1 |
| biop_version.minor | 8 | uimsbf | 0x00 | BIOP minor version 0 |
| byte_order | 8 | uimsbf | 0x00 | big endian byte ordering |
| message_type | 8 | uimsbf | 0x00 | |
| message_size | 32 | uimsbf | * | |
| objectKey_length | 8 | uimsbf | N1 | |
| for (i = 0; i <N1; i++) { | ||||
| objectKey_data_byte | 8 | uimsbf | + | |
| } | ||||
| objectKind_length | 32 | uimsbf | 0x00000004 | |
| objectKind | 4*8 | uimsbf | 0x64697200 | "dir" type_id alias |
| objectInfo_length | 16 | uimsbf | N2 | |
| for (j = 0; j < N2; j++) { | ||||
| objectInfo_data_byte | 8 | uimsbf | + | |
| } | ||||
| serviceContextList_count | 8 | uimsbf | N3 | serviceContextList |
| for (k = 0; k < N3 ; k++) { | ||||
| serviceContextList_data_byte | 8 | uimsbf | + | |
| } | ||||
| messageBody_length | 32 | uimsbf | + | |
| bindings_count | 16 | uimsbf | N4 | Binding |
| for (l = 0; l < N4; l++) { | ||||
| BIOP::Name { | ||||
| nameComponents_count | 8 | uimsbf | N5 | |
| for (m = 0; m < N5; m++) { | ||||
| id_ length | 8 | uimsbf | N6 | NameComponent id |
| for (n = 0; n <N6; n++) { | ||||
| id_data_byte | 8 | uimsbf | + | |
| } | ||||
| kind_length | 8 | uimsbf | N7 | NameComponent kind |
| for (p = 0; p < N7; p++) { | ||||
| kind_data_byte | 8 | uimsbf | + | as type_id |
| } | ||||
| } | ||||
| } | ||||
| bindingType | 8 | uimsbf | + | 0x01 for nobject 0x02 for context |
| IOP::IOR() | objectRef (see IOR description in TR 101 202) | |||
| objectInfo_length | 16 | uimsbf | N8 | |
| for (r = 0; r < N8; r++) { | ||||
| objecIinfo_data_byte | 8 | uimsbf | + | |
| } | ||||
| } | ||||
| } |
Directory messages and Service Gateway messages have exactly the same
structure (after all, as service gateway is a directory – it just happens
to be the root directory of the carousel). The value of the objectKind field for a Directory message is 0x64697200, corresponding to the
ASCII characters ‘dir’ (with a terminating zero). For a Service
Gateway message, the value of this field is 0x73726700 (‘srg’ – again
followed by as terminating zero).
Directory objects contain a list of references to the files and directories
that they contain. These are carried as IOR structures (Interoperable
Object References). We will take a detailed look at the format of
IORs later in this tutorial.
Stream messages
The structure for BIOP Stream messages is as follows:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| BIOP::StreamMessage { | ||||
| magic | 32 | uimsbf | 0x42494F50 | "BIOP" |
| biop_version.major | 8 | uimsbf | 0x01 | BIOP major version 1 |
| biop_version.minor | 8 | uimsbf | 0x00 | BIOP minor version 0 |
| byte_order | 8 | uimsbf | 0x00 | big endian byte ordering |
| message_type | 8 | uimsbf | 0x00 | |
| message_size | 32 | uimsbf | * | |
| objectKey_length | 8 | uimsbf | N1 | |
| for (i = 0; i <N1; i++) { | ||||
| objectKey_data_byte | 8 | uimsbf | + | |
| } | ||||
| objectKind_length | 32 | uimsbf | 0x00000004 | |
| objectKind | 4*8 | uimsbf | 0x73747200 | "str" type_id alias |
| objectInfo_length | 16 | uimsbf | N6 | |
| DSM::Stream::Info_T { | objectInfo | |||
| aDescription_length | 8 | uimsbf | N2 | aDescription |
| for (j = 0; j < N2; j++) { | ||||
| aDescription_bytes | 8 | uimsbf | + | |
| } | ||||
| duration.aSeconds | 32 | uimsbf | + | AppNPT seconds |
| duration.aMicroseconds | 32 | uimsbf | + | AppNPT microseconds |
| audio | 8 | uimsbf | + | |
| video | 8 | uimsbf | + | |
| data | 8 | uimsbf | + | |
| } | ||||
| for (k = 0; k < N6 – (N2+10); k++) { | ||||
| objectInfo_byte | 8 | uimsbf | + | |
| } | ||||
| serviceContextList_count | 8 | uimsbf | N3 | serviceContext List |
| for (l = 0; l < N3; l++) { | ||||
| serviceCcontextList_data_byte | 8 | uimsbf | + | |
| } | ||||
| messageBody_length | 32 | uimsbf | + | |
| taps_count | 8 | uimsbf | N4 | |
| for (m = 0; l < Nt; l++) { | ||||
| id | 16 | uimsbf | 0x0000 | undefined |
| use | 16 | uimsbf | + | see table below |
| association_tag | 16 | uimsbf | + | |
| selector_length | 8 | uimsbf | 0x00 | No selector |
| } | ||||
| } |
Stream messages use the value 0x73747200 (‘str’ with a terminating zero) for the objectKind field.
One element that may not be familiar in this data structure is a list of taps. A tap is a structure used in DSM-CC to refer to a specific MPEG stream (which may be an elementary stream or a complete program) or to a DSM-CC data carousel DII or DSI message. In the case of Stream messages, these taps refer to the stream that the message describes. There may be one tap that refers to the complete stream, or there may be several taps that refer to a number of elementary streams that make up a single logical Stream as described in the object carousel.
For instance, a DVB service may contain two audio tracks for different languages. A DSM-CC object carousel may contain a single Stream object that refers to that entire service, but it may also contain two separate Stream objects that each refer to the video portion of the stream and one of the two audio streams (or it may contain one Stream object that refers to the video stream and one of the audio streams while completely ignoring the other).
| Mnemonic | Value | Description |
|---|---|---|
| STR_STATUS_AND_EVENT_USE | 12 | Used in a Stream or Stream Event message to refer to sub-streams that make up the stream being referred to. |
| STR_EVENT_USE | 13 | |
| STR_STATUS_USE | 14 | |
| STR_NPT_USE | 11 | |
| BIOP_ES_USE | 24 | the tap refers to a single MPEG elementary stream |
| BIOP_PROGRAM_USE | 25 | the tap refers to a complete MPEG2 Program (for instance, a DVB service) |
Stream Event messages
The last type of BIOP message is the Stream Event message. This has the following structure:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| BIOP::StreamEventMessage { | ||||
| magic | 32 | uimsbf | 0x42494F50 | "BIOP" |
| biop_version.major | 8 | uimsbf | 0x01 | BIOP major version 1 |
| biop_version.minor | 8 | uimsbf | 0x00 | BIOP minor version 0 |
| byte_order | 8 | uimsbf | 0x00 | big endian byte ordering |
| message_type | 8 | uimsbf | 0x00 | |
| message_size | 32 | uimsbf | * | |
| objectKey_length | 8 | uimsbf | N1 | |
| for (i = 0; i <N1; i++) { | ||||
| objectKey_data_byte | 8 | uimsbf | + | |
| } | ||||
| objectKind_length | 32 | uimsbf | 0x00000004 | |
| objectKind | 4*8 | uimsbf | 0x73746500 | "ste" type_id alias |
| objectInfo_length | 16 | uimsbf | N6 | |
| DSM::Stream::Info_T { | ||||
| aDescription_length | 8 | uimsbf | N2 | aDescription |
| for (i = 0; i < N2; i ++) { | ||||
| aDescription_bytes | 8 | uimsbf | + | |
| } | ||||
| duration.aSeconds | 32 | uimsbf | + | see BIOP::StreamMessage() |
| duration.aMicroseconds | 32 | uimsbf | + | see BIOP::StreamMessage() |
| audio | 8 | uimsbf | + | see BIOP::StreamMessage() |
| video | 8 | uimsbf | + | see BIOP::StreamMessage() |
| data | 8 | uimsbf | + | see BIOP::StreamMessage() |
| } | ||||
| DSM::Event::EventList_T { | ||||
| eventNames_count | 16 | N3 | ||
| for (i = 0; i <N3; i++) { | ||||
| eventName_length | 8 | N4 | ||
| for (j = 0; j < N4; j ++) { | ||||
| eventName_data_byte | 8 | (including zero terminator) | ||
| } | ||||
| } | ||||
| } | ||||
| for (i = 0; i < N6 – (N2 + 10) – (2 + N3 + sum(N4)) ; i++) { |
||||
| objectInfo_byte | 8 | |||
| } | ||||
| serviceContextList_count | 8 | 0x00 | Empty ServiceContext List | |
| for (i = 0; i < N3; i++) { | ||||
| serviceContexList_ data_byte | 8 | |||
| } | ||||
| messageBody_length | 32 | |||
| taps_count | 8 | N5 | ||
| for (i = 0; i < N5; i++) { | ||||
| id | 16 | uimsbf | 0x0000 | undefined |
| use | 16 | uimsbf | + | see table above |
| association_tag | 16 | uimsbf | + | |
| selector_length | 8 | uimsbf | 0x00 | No selector |
| } | ||||
| eventIds_count | 8 | uimsbf | N3 | ( = eventNames_count) |
| for (i = 0; i < N3; i++) { | ||||
| eventId | 16 | uimsbf | ||
| } | ||||
| } |
Stream event messages use the value ‘ste’ for the objectKind field (0x73746500 hex).
As with Stream messages, a Stream Event message contains a list of taps that refer to the stream containing the stream events. More than one tap may be needed, because the Stream Event object may refer to an elementary stream carrying NPT data as well as to the streams carrying actual stream event descriptors.
Referring to streams and objects
Association Tags
As we have just seen, several BIOP messages have a need to refer to MPEG programs or elementary streams. While the most obvious way to refer to an MPEG stream is its PID, that has two distadvantages:
- PIDs only refer to elementary streams, not whole programs
- The PID for any stream can be changed when it is re-multiplexed. This means we would have to update every reference in an object carousel when we re-multiplex the stream.
DVB introduced the concept of component tags to solve this very problem, but unfortunately component tags are not available in non-DVB systems. To solve this problem, DSM-CC introduces another identifier called an association tag. This serves the same purpose as a component tag in DVB systems: it provides a way to uniquely identify a stream that is easy for the broadcaster and receiver to use, and which is not affected by re-multiplexing.
The association tag is attached to a stream by inserting an association tag descriptor in the stream’s PMT entry. Every program has a PMT, and each PMT contains a list of the streams in that program. Each stream in that list can have a series of descriptors: this is where the association tag descriptor is carried.
More details about the association tag descriptor can be found in the section on DSM-CC and service information.
Taps
It’s not enough to be able to refer to streams alone, however. Some BIOP messages need to refer to specific Download Control Messages within the data carousel that carries the object carousel. While we could define another structure for describing a reference to a Download Control Message, it makes sense to use the same structure that we would to refer to a stream: after all, a refernece to a Download Control Message must also include a reference to the stream that contains them.
For this reason, references to streams or Download Control Messages are coded as taps. A tap uses the association tag that is introduced by DSM-CC to refer to specific streams without relying on PIDs or on data that is specific to one SI system. The DSM-CC spec is extremely vague about what information is actually contained within a tap, but thankfully DVB provides us with a bit more detail. Of course, this means that what is defined in the DVB data broadcasting specification is specific to DVB and OCAP systems.
Each tap contains the following fields:
| Syntax | Bits | Type |
|---|---|---|
| DSM-CC tap { | ||
| id | 16 | uimsbf |
| use | 16 | uimsbf |
| association_tag | 16 | uimsbf |
| selector_length | 8 | uimsbf |
| if (selector_length > 0) { | ||
| selector { | ||
| selector_type | 16 | uimsbf |
| transactionId | 32 | uimsbf |
| timeout | 32 | uimsbf |
| } | ||
| } | ||
| } |
Fields in blue are optional and are not used in DVB or OCAP systems. The id field is a value that identifies a particular tap. This is private to the carousel, and is simply a 16-bit value
The use field indicates exactly how that tap is used. For the sake of this discussion, we can assume that this refers to the type of object that the tap points to, such as an a DSM-CC data carousel message, an elementary stream or a complete MPEG-2 program. The following use values are supported:
| Mnemonic | Value | Description |
|---|---|---|
| BIOP_DELIVERY_PARA_USE | 22 | Used in an IOR (see the next section) to indicate that the tap refers to a specific DII message in a carousel |
| BIOP_OBJECT_USE | 23 | Used in a DII message that describes modules containing an object carousel to indicate that the tap refers to the elementary stream on which the modules described by that DII are broadcast |
| BIOP_ES_USE | 24 | the tap refers to a single MPEG elementary stream |
| BIOP_PROGRAM_USE | 25 | the tap refers to a complete MPEG2 Program (for instance, a DVB service) |
| STR_STATUS_AND_EVENT_USE | 12 | Used in a Stream or Stream Event message to refer to sub-streams that make up the stream being referred to. |
| STR_EVENT_USE | 13 | |
| STR_STATUS_USE | 14 | |
| STR_NPT_USE | 11 |
Some of the places where these values are used (especially the first two) may not be clear at the moment, but we’ll explain these later in this tutorial
The value given in the association_tag field identifies
an elementary stream. This identifies the elementary stream carrying the carousel in a way that isn’t dependent on PIDs or other information that may change. Later in this tutorial, we’ll see how the association tag is linked to a particular elementary stream.
The selector field allows a tap to get more specific than just identifying the stream. For DVB and OCAP data broadcasting, the syntax of the selector is defined a little better than it is in standard DSM-CC. In this case, each selector has a type. The transactionId field corresponds to the transaction ID of the DSM-CC message that this tap refers to. This enables the tap to identify a specific DII or DSI message in a data carousel, and thus a group of modules. As we saw above, this is used by IOR references to refer to a specific message within a carousel.
The selector is optional: any taps with a selector length of zero do not contain any more information relating to the selector, and in this case the fields marked in blue above are not present. In general DSM-CC implementations, the selector is not as well-defined as we have seen here, and is just a sequence of up to 255 bytes.
Interoperable Object References
When one DSM-CC object needs to refer to another object, we need some interoperable way of doing this. Given that DSM-CC is based on CORBA, it uses the CORBA approach to this. This approach is called an Interoperable Object Reference, or IOR. Put simply, it gives each object a unique identifier that can be used instead of a pointer to that object.
Each IOR contains a profile body for every location that the file is available from. This allows a single IOR to provide multiple sources for the same file. In the case of DSM-CC, however, this feature is not used very often and an IOR normally contains one profile body that points to an object in a DSM-CC object carousel. As broadband IP connections become more common, this may change – in the future, an IOR may provide references to an object either from a DSM-CC object carousel or from a website, for instance.
For DSM-CC systems, the most common type of profile body is the BIOP profile body. This contains an object location and a ConnBinder. The object location locates the object within a given carousel, and contains fields giving the carousel ID, the module ID and the object key of the specific object in the carousel. These three values taken together give a specific reference to the object in question.
Of course, as well as knowing which object we are referring to, we also need to know how to find it. The ConnBinder contains one or more taps that refer to the DSM-CC data carousel messages that contain the message. In this case, each tap refers to the DownloadInfoIndication (DII) message describing the module in the DSM-CC data carousel that includes the object in question. This allows the receiver to access the object referred to by the IOR as quickly as possible.
Interoperable Object References and the types of profile body.
The main restriction of the BIOP profile body is that it can only refer to objects in the same carousel. If we want to refer to objects in a different carousel, we need to use the Lite Options profile body. This contains a different set of data to identify the object in a different carousel. We won’t discuss this in great detail, except to say that the reference consists of two parts: a reference to the carousel containing the object, and then the full path of the object within the carousel.
The second part of this is easy: the path is carried as a set of path components, with each one having a name and a type (that identifies the type of DSM-CC object that is referred to by that component). The first part causes some more problems, however: in order to refer to another object carousel, we need some unique way to identify it. For this, we use the NSAP address of the carousel. This identifier is guaranteed to be unique to that carousel, and so gives us an ideal reference. NSAP addresses are a 20-byte structure that have a well-defined format. Since NSAP addresses can be used on a wide range of systems, the first part of the address is a general description of the type of NSAP address so that the middleware can parse it correctly, The second part is specific to the type of network in which it is used, and describes the actual address. NSAPaddresses for DVB object carousels have the structure shown below:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| DVBcarouselNSAPaddress () { | ||||
| AFI | 8 | uimsbf | 0x00 | NSAP for private use |
| type | 8 | uimsbf | 0x00 | Object carousel NSAP address |
| carouselId | 32 | uimsbf | ||
| specifierType {IEEE OUI} | 8 | uimsbf | 0x01 | IEEE OUI |
| specifierData | 24 | uimsbf | 0x<DVB> | Constant for DVB OUI |
| dvb_service_location () { | ||||
| transport_stream_id | 16 | uimsbf | ||
| original_network_id | 16 | uimsbf | ||
| service_id | 16 | uimsbf | (= MPEG2 program_number) | |
| reserved | 32 | uimsbf | ||
| } |
In a more general NSAP address, the dvb_service_location field is actually 10 bytes of private data that can contain any information needed to refer to the content in question.
We have actually already seen NSAP addresses in use, but not actually called them that. For instance, the server ID field in a DSI message is actually an NSAP address (although this is not used in data broadcasting scenarios).
Transporting object carousels in data carousels
Object carousels impose a few limitations on the format of data carousel messages. While these are not significant, there is one that we need to be aware of. Data carousel DownloadInfoIndication messages that are used as part of an object carousel must contain the following structure in the moduleInfoByte field:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| BIOP::ModuleInfo { | ||||
| ModuleTimeOut | 32 | uimsbf | + | |
| BlockTimeOut | 32 | uimsbf | + | |
| MinBlockTime | 32 | uimsbf | + | |
| taps_count | 8 | uimsbf | N1 | |
| for (i = 0; i < N1; i++) { | ||||
| id | 16 | uimsbf | 0x0000 | user private |
| use | 16 | uimsbf | 0x0017 | BIOP_OBJECT_USE |
| association_tag | 16 | uimsbf | + | |
| selector_length | 8 | uimsbf | 0x00 | |
| } | ||||
| UserInfoLength | 8 bits | uimsbf | N2 | |
| for (j = 0; j < N2; j++) | ||||
| userInfo_data_byte | 8 | uimsbf | + | (including zero terminator) |
| } | ||||
| } |
Object carousels also use DownloadServerInitiate messages to carry a description of the service gateway, and will thus always be two-layer carousels. A DownloadServerInitiate message used in an object carousel will carry the following structure in its private
data field:
| Syntax | Bits | Type | Value | Comment |
|---|---|---|---|---|
| ServiceGatewayInfo () { | ||||
| IOP::IOR() | + | See IOR syntax in TR 101 202 | ||
| downloadTaps_count | 8 | N1 | software download Taps | |
| for (i = 0; i < N1; i++) { | ||||
| Tap() | 8 | |||
| } | ||||
| serviceContextList_count | 8 | N2 | serviceContextList | |
| for (i = 0; i < N2; i++) { | ||||
| serviceContextList_data_byte | 8 | + | ||
| } | ||||
| userInfoLength | 16 | N3 | user info | |
| for (k = 0; k < user info length; k++) { | ||||
| userInfo_data_byte | 8 | + | ||
| } | ||||
| } |
The IOR field contains an Interoperable Object Reference to the Service Gateway BIOP message for that carousel.
The use of this structure to describe a service gateway has implications that may not be obvious at first. It means that an object carousel will always be carried by a two-layer carousel. Since every object carousel must have a service gateway (by definition – the root directory of the carousel is the service gateway), it must also have a data carousel DSI message to describe that service gateway.