Digital control channels having logical channels supporting broadcast SMS5768276Abstract A communications system in which information is transmitted in successive time slots grouped into a plurality of superframes which are, in turn, grouped into a plurality of hyperframes. A remote station is assigned to one of the time slots in each of the superframes for paging the remote station, each hyperframe including at least two superframes, and the information sent in the assigned time slot in one superframe in each hyperframe is repeated in the assigned time slot in the other superframe(s) in each hyperframe. Each superframe can include a plurality of time slots used for sending paging messages to remote stations, grouped into a plurality of successive paging frames, and the time slot to which the remote station is assigned is included once in every paging frame. Also, each superframe may include time slots comprising a logical channel for broadcast control information and time slots comprising a logical paging channel. Information sent in the assigned time slot may direct the remote station to read the broadcast control information, and the information may have been encoded according to an error correcting code and include a plurality of bits having polarities that are inverses of cyclic redundancy check bits produced by the encoding. Also, the broadcast control information may comprise special messages that are included in respective time slots comprising a logical special message channel, the time slots of the special message channel may be grouped in successive SMS frames, and the SMS frames may be synchronized to start with a start of a superframe. Claims What is claimed is: Description BACKGROUND
______________________________________
Number of Slots Used Slots Rate
______________________________________
1 1 half
2 1, 4 full
4 1, 4, 2, 5 2 full
6 1, 4, 2, 5, 3, 6
3 full
______________________________________
As explained above, each superframe comprises a predetermined number of successive time slots (full-rate) of a DCCH. Since a complete set of F-BCCH information is sent in each superframe and since the first slot of each superframe is a F-BCCH slot, each superframe is the interval between such initial F-BCCH slots. It is currently preferred that each superframe consist of thirty-two such time slots, which are distributed among the logical channels F-BCCH, E-BCCH, S-BCCH, and SPACH as illustrated in FIG. 5 for example. Thus, the duration of each logical superframe is simply 32 TDMA blocks/superframe * 20 msec/TDMA block=640 msec, which spans 96 consecutive physical time slots on the radio channel. It will be appreciated that this selection represents a balance of several factors that Applicants' currently deem most useful. For example, using thirty-two slots, which is an integer power of two, simplifies the implementation of various counters in existing hardware that is based on binary signal processing. Also, using thirty-two-slot superframes balances call set-up delay against paging channel (and other channel) capacity. For a given amount of BCCH information to be transmitted, using longer superframes would increase paging capacity, but would also increase the average set-up delay; using shorter superframes would decrease the average set-up delay to an extent, but would also decrease paging capacity and devote a greater proportion of each superframe to overhead information. Different balances can be struck that would nevertheless fall within the spirit of Applicants' invention. In order to locate each time slot in each superframe and thus provide the enhanced sleep capabilities made available by Applicants' invention, a superframe phase (SFP) count, which increments by one for each full-rate DCCH slot in a given superframe, is included as part of the information broadcast in each downlink DCCH slot. The SFP value sent in the first slot (an F-BCCH slot) of each superframe may be assigned the value 0; the next slot of the same logical DCCH is assigned an SFP value of 1, etc. Thus, for a system using superframes of thirty-two slots each, the SFP value increments modulo-32, and the SFP value sent in each slot requires five bits. For a half-rate DCCH, only half of the values (e.g., 0, 2, 4, . . . , 30) need be used to identify the slots in each superframe of the DCCH. It will be appreciated that such a modulo-32 up-counter could be replaced by a modulo-32 down-counter, and for a communication system that does not employ superframes having a fixed number of time slots, the modulo-32 up-counter would be replaced by a down counter for indicating the next occurrence of the F-BCCH, or other desired overhead information. It is only necessary for the information in a slot to include some indication of that slot's position in time with respect to the next occurring time slot carrying the important overhead information. It is also desirable that the information indicate the start of the superframe/hyperframe/paging-frame structures, i.e., that the boundaries of the frame structures all be synchronized with the next occurring time slot carrying the important overhead information, but such synchronization is not necessary. Two possible formats for the information sent in the slots of the reverse DCCH are shown in FIGS. 8a and 8b, and a preferred information format in the slots of the forward DCCH is shown in FIG. 8c. These formats are substantially the same as the formats used for the DTCs under the IS-54B standard, but new functionalities are accorded to the fields in each slot in accordance with Applicants' invention. In FIGS. 8a-8c, the number of bits in each field is indicated above that field. In general, messages (Layer 2 user data bits) to be carried by the slots are mapped onto the two DATA fields sent in each slot, and in the downlink slots, encoded SFP values are sent in the CSFP fields that uniquely identify each slot according to each slot's relative position in its superframe. Also in the downlink slots, the BRI, R/N, and CPE fields contain the information used in the random access scheme for Layer 2 ARQ on the RACH; comparable Layer 2 ARQ fields could be included in the uplink slots. In the forward DCCH (FIG. 8c), the DATA fields total 260 bits in length, the CSFP field carries twelve bits, and the BRI, R/N, CPE fields for shared channel feedback total twenty-two bits. In the reverse DCCH, the DATA fields total either a normal 244 bits in length (FIG. 8a) or an abbreviated 200 bits (FIG. 8b). The bits sent in the G, R, PREAM, SYNC, SYNC+, and AG fields are used in a conventional way to help ensure accurate reception of the CSFP and DATA fields, e.g., for synchronization, guard times, etc. For example, the SYNC field would be the same as that of a DTC according to IS-54B and would carry a predetermined bit pattern used by the base stations to find the start of the slot. Also, the SYNC+ field would include a fixed bit pattern to provide additional synchronization information for the base stations, which would set their receiver gains during the PREAM field so as to avoid signal distortion. Referring again to FIG. 8c, the CSFP field in each DCCH slot conveys the SFP value that enables the mobile stations to find the start of each superframe. The SFP values are preferably encoded with a (12,8) code, similar to the way the DVCC is encoded according to the IS-54B standard; thus, the CSFP field is preferably twelve bits in length, and the unencoded SFP consists of eight bits. Encoding the SFP values in this way has the advantage of using the hardware and software already present in the mobile phone for handling the DVCC. Also, the four check bits are preferably inverted, enabling a mobile to use the information sent in the CSFP field to discriminate between a DCCH and a DTC since the CSFP of a DCCH and the CDVCC of a DTC have no common codewords. Other ways to discriminate DCCHs from DTCs are described in U.S. Pat. No. 5,603,081. In view of the importance of the SFP to the operation of the system, a mobile station might decode the CSFPs in several slots in order to ensure accuracy since the CSFP in any individual slot is less well protected by encoding and time diversity than the Layer 3 message in the DATA fields. When each superframe includes thirty-two slots, the three most significant bits in each eight unencoded SFP bits may be set to zero. It will be appreciated that the unused SFP bits could be used for particular purposes, e.g., to handle superframes consisting of more than thirty-two slots each or for Layer 1 power control messages. Also, the three unused SFP bits could be used, either alone or in combination with other unused (reserved) bits transmitted in each slot, for increasing the redundancy or strengthening the error correction coding of the SFP, if determined to be necessary. It will be appreciated that the SFP information could be included in the Layer 2 frame header information, rather than in separate Layer 1 fields as shown. Also, in a system using thirty-two-slot superframes, it is currently preferred that the sixteen CRC, or check, bits in the Layer 2 frames sent in the BCCH slots are inverted, while the sixteen check bits in the Layer 2 frames sent in the SPACH slots are not inverted. Using the check bits in this way is advantageous in some situations where it is necessary to re-assign a mobile station to another paging slot. For example, if a system has been using twelve slots of a thirty-two-slot superframe for the BCCH and wants to use thirteen slots for the BCCH, mobile stations assigned to the first paging slot after the BCCH slots must be informed that they should monitor another paging slot. The mobiles could obtain this information by decoding one or two bits that would identify the type of slot being decoded, but at a cost of reduced bandwidth. In Applicants' system, the mobile stations will recognize that something has changed when they spot the inverted CRC bits, and in response they will re-read the F-BCCH, including the new DCCH structure message. A hyperframe count and a primary SF indicator are also preferably included in the information carried by the BCCH slots; in particular as described in more detail below, these information elements are included in the DCCH structure message carried by the F-BCCH. The hyperframe count identifies which hyperframe of a higher-level structure of paging frames and SMS frames is currently being broadcast, as described below in connection with FIG. 10. In accordance with Applicants' invention, four paging frame classes and/or a plurality of broadcast SMS sub-channels may be provided as described below. The primary superframe indicator is a single bit that toggles to indicate whether the current superframe is the primary or the secondary superframe in the current hyperframe; when its value is zero, the current superframe may be the primary, and vice versa. In one embodiment of Applicants' invention, the hyperframe count counts modulo-12. FIG. 9 shows a currently preferred partitioning of the Layer 2 user data bits before channel encoding. The DATA fields in the logical channels BCCH, SPACH, and RACH (normal and abbreviated) preferably use 1/2-rate convolutional encoding; thus, the two DATA fields in each forward DCCH slot carry 109 plaintext, or unencoded, BCCH or SPACH bits; and the two DATA fields in each reverse DCCH slot carry either a normal 101 plaintext RACH bits or an abbreviated 79 plaintext RACH bits. Also, the encoded user data bits are preferably interleaved between the two DATA fields in each slot, but they are not interleaved among DATA fields in different slots in order to enable the longer sleep times available from Applicants' invention. Interleaving may be done according to suitable convenient matrices, like those used under the IS-54B standard. Different DCCHs may be assigned to different radio channel frequencies, and a different number of slots may be allocated to the BCCH on each DCCH. Layer 2/3 information may also be different for each DCCH, but this is not required. In an embodiment in which each DCCH includes its own BCCH, much information is redundant from DCCH to DCCH, resulting in a loss of paging capacity. In another embodiment, DCCHs may be organized in master-slave relationships, in which full BCCH information would be available only on the master DCCH; a mobile monitoring a slave DCCH would acquire its BCCH information by changing to its slave's corresponding master DCCH. It is currently preferred that each frequency carry a full set of BCCH information and a mobile station always acquire all its BCCH information on the same frequency as its assigned PCH channel. The structure of the DCCH transmitted on the F-BCCH in the first slot of each superframe is the most important information for a mobile to acquire. An advantageous DCCH structure message comprises the information elements listed in the following table.
______________________________________
Information Element I E Type Bit Length
______________________________________
Message type M 8
Number of F-BCCH slots
M 2
Number of E-BCCH slots
M 3
Number of S-BCCH slots
M 4
Number of Skipped slots
M 3
E-BCCH change notification flag
M 1
Hyperframe count M 4
Primary superframe indicator
M 1
Number of DCCH slots on this frequency
M 2
MAX.sub.-- SUPPORTED.sub.-- PFC
M 2
PCH.sub.-- DISPLACEMENT
M 3
Additional DCCH frequencies
O 23-114
Total = 33-
147
______________________________________
M = Mandatory
O = Optional
As described above, the mobile station normally monitors only one of the PCH slots in a superframe to minimize power consumption, or battery drain. Since some paging messages may be longer than the capacity of a single time slot, each PCH slot carries a PCON bit that may be set to cause the assigned mobile station to read additional SPACH slots, the number of which is advantageously indicated by a parameter PCH.sub.-- DISPLACEMENT sent on the F-BCCH. The additional slots to be read preferably are separated by at least 40 msec (one TDMA frame) from the assigned PCH slot for both full- and half-rate DCCHs. For example, for a full-rate DCCH, the mobile station would attempt to read every other SPACH slot up to the number indicated by the PCH.sub.-- DISPLACEMENT parameter. This is advantageous in that it reduces the trunking loss caused by the creation of the several distinct paging channels. Also, using every other SPACH slot in this way gives a mobile station time for processing its received information to determine whether it must read additional slots. If every SPACH slot were used instead of at least every other one, a mobile station having a slow processing unit might not complete processing by the time the next SPACH slot occurred; since the mobile would not yet be aware that the PCON bit was set, it would have to read the next slot even if that were unnecessary and sleep mode performance would suffer. Also, the transmission of long ARCH or SMSCH messages to a first mobile station may be interrupted to allow for the transmission of messages to a second mobile station. Each interruption of an ARCH or SMSCH message by another SPACH message may be limited to no more than a predetermined number n of time slots, or by Layer 3 timeout for SMSCH or ARCH messages. It will be understood that Layer 3 timeout refers to the common practice of waiting for a response to a Layer 3 message only for a predetermined period. The number of interruptions each mobile station may suffer may also be limited. Ordinarily, the probability of a successful transmission of a Layer 3 message is inversely related to the length of the message. Since the probability can be quite small for long messages, a simple-minded system would spend much of its time re-transmitting or re-reading entire messages that were not properly received. In Applicants' system, Layer 3 paging and broadcast SMS messages are mapped onto Layer 2 frames, and these are organized in structures called paging frames and SMS frames, respectively. For the BCCH, if a Layer 2 frame is not received properly, it is not necessary to re-read the entire Layer 3 message but only the improperly received Layer 2 frame. The ARCH and RACH can use ARQ. In accordance with an aspect of Applicants' invention, the superframes and hyperframes on each DCCH are grouped into a succession of paging frames, each of which includes an integer number of hyperframes and is a member of one of a plurality of paging frame classes; hence, the PCH slots have the paging frame structure. In accordance with one aspect of Applicants' invention, the mobile station reads its assigned PCH slot only in the hyperframes of its allocated paging frame class. (As described above, each mobile station is allocated a specific PCH sub-channel within a paging frame based preferably on the mobile's IS-54B MIN identity.) In many cases, mobile stations would be allocated a paging frame class that would cause the mobiles to read their assigned PCH slots in each hyperframe; this minimizes call set-up time and sleep duration. But other paging classes would have the mobiles read PCH slots in more widely separated hyperframes, delaying call set-ups but increasing sleep times to as much as 123 seconds for some types of paging frame structure. Thus, it will be appreciated that PCH slots are included in every superframe but the PCH slot assigned to a given mobile may not be. Referring to the exemplary table shown in FIG. 10, primary and secondary PCH slots p and s in the primary and secondary superframes, respectively, of each hyperframe may be grouped in one of four PF classes PF.sub.1 -PF.sub.4, which are distinguished by how frequently the PCH slot information is repeated. Class PF.sub.1 may be called the "lowest" PF class because PCHs in this class repeat their information with the lowest duration between repeats; in FIG. 10, the PCH slot is repeated in each successive hyperframe (i.e., in every successive superframe). Class PF.sub.4 may be called the "highest" PF class because PCHs in this class repeat their information with the highest duration between repeats; in FIG. 10, the PCH slot is repeated only every fourth hyperframe. As described above, the PCH information in a primary superframe is guaranteed to be repeated in the corresponding secondary superframe. In FIG. 10 for paging frame class PF(i), where i=2, 3, 4, only the PCH assignments which are aligned to HF.sub.0 are shown for illustration purposes. In the embodiment illustrated by FIG. 10, there are only four paging frame classes that are linearly related, yielding maximum sleep times of eight superframes, or 5.12 seconds. Longer sleep times can be obtained by providing more classes that are exponentially related. For example, sleep times of 123 seconds are obtained in a system having eight paging frame classes in which the delays double from class to class. It will be understood that long sleep times can result in access delays that are unacceptable for typical telephone use; for example, most callers attempting to reach a mobile would be unwilling to wait 123 seconds after dialing the mobile's number for contact to be established. Nevertheless, such delays may be tolerable in some cases, such as remote polling of equipment like soft-drink dispensers. In an embodiment using the table illustrated in FIG. 10, the least common multiple of the indices of the four paging frame classes is twelve; this is the reason that the HF counter counts modulo-12, as described above. Three other terms used in describing the operation of the PF classes are default PF class, assigned PF class, and current PF class. The default PF class is the class assigned to the mobile station when its subscription to the system is entered. If the default PF class happens to be higher than the highest class supported by a DCCH, as defined by the parameter MAX.sub.-- SUPPORTED.sub.-- PFC in the DCCH structure message, the mobile would use the PF class defined by MAX.sub.-- SUPPORTED.sub.-- PFC. The assigned PF class refers to a PF class assigned to the mobile by the system, for example in the system's response to a registration request by the mobile. The PF class actually used during a communication may be called the current PF class. According to other exemplary embodiments of the present invention, broadcast short message service (SMS) can be supported by way of logical sub-channeling in a variety of ways. Two examples will be discussed in detail, with other modifications and adaptations described after the detailed examples. In one exemplary embodiment of Applicants' invention, depicted in FIGS. 11-13, the S-BCCH slots in successive superframes are grouped into a succession of fixed-length SMS frames, each preferably consisting of twenty-four superframes (twelve hyperframes) as shown in FIG. 11. This S-BCCH frame structure enables messages to be sent with highly variable periodicity without sacrificing capacity, and as described below, it avoids requiring the mobile stations to re-read constantly the entire S-BCCH information when only one of the many messages sent has changed. Also, choosing an SMS frame structure that is conveniently related to the paging frame class structure enables counters that are already in use for one purpose (paging) to be re-used for another purpose (SMS broadcast messaging). The SMS frames are advantageously divided into a plurality of sub-channels, each having its own repetition cycle defined in terms of units of possible SMS frames. For most practical situations, the sub-channel repetition time should not be too long. In a manner similar to the handling of the F-BCCH change flag described above, a mobile station is informed of a change in the contents of particular sub-channels through an SMS transition flag (TF) included in its PCH slot information. Currently, four SMS sub-channels are preferred for this exemplary embodiment, and the SMS sub-channels are sub-multiplexed on the S-BCCH channel in units of SMS frames, e.g., SMS frame SMS(i), where i=1, . . . , N, as illustrated in FIG. 12. It will be understood that each (Layer 1) time slot carries a respective SMS frame and that a Layer 3 SMS message can span several SMS frames. An SF number is advantageously derived from the hyperframe count and primary superframe indicator sent on the BCCH as follows: SF number=2*HF count+primary SF indicator. The first S-BCCH slot(s) within each SMS frame (superframe 0) would contain a header that describes the structure of the SMS sub-channel. As noted above, the number of superframes within each SMS frame is fixed for this exemplary embodiment, and thus the number of slots assigned to the SMS frame are 0, 24, 48, 72, . . . (full-rate), depending on how many slots per superframe are assigned to S-BCCH. The SMS frame is aligned to start at HF counter equal to zero and in a primary superframe to help the mobile synchronize to the SMS frame structure. In this way, SMS frames are synchronized to the hyperframes and superframes, although it will be appreciated that the start of an SMS frame is offset from the start of a hyperframe (or a primary superframe) since the S-BCCH slots are not the first slots in a superframe. Furthermore, regardless of how many paging frame classes are supported, the system increments the hyperframe count to provide SMS frame synchronization information to the mobile station. According to Layer 2 information found in every first slot in each SMS frame, the set of messages in an SMS frame SMS(i) may span a number M(i) of SMS frames before a cycle is completed. Regardless of varying message set cycles among the sub-channels, SMS frame SMS(i) is always followed by SMS frame SMS((i+1) mod N+1) in order of transmission in this exemplary embodiment. Thus, Layer 3 broadcast SMS messages can span several SMS frames, which represents a tradeoff between the number of slots in each superframe devoted to SMS broadcast and the time needed for message transmission. A transition flag (TF) is provided for each SMS sub-channel, and the flags for all SMS sub-channels are submultiplexed onto a single flag, transmitted on the SPACH channel, that points to the next logical SMS frame to be read. For example, FIG. 12 shows flag TF(2) pointing to SMS frame SMS(2). If the transition flag for a sub-channel indicates a change, the mobile station reads an S-BCCH header field at the start of the next logical SMS frame to obtain further information, as described more fully below. Header information describes the sub-channeling of the broadcast SMS channel and is provided in the first slot of every SMS frame. The mobile can also find the Layer 3 structure of the SMS frame associated with this header. A suitable SMS Header information element located at the start of every SMS frame is shown in the table below.
______________________________________
Information Element
Range (Logical) Bits
______________________________________
Number of Sub-channels
1-4 2
Sub-channel Number
1-4 2
Phase Length of Sub-ch. Cycle
1-64 6
Phase Number of Sub-ch. Cycle
1-64 6
Number of SMS Messages (N)
1-64 (set to 1 plus value in
6
field)
.smallcircle. SMS Message ID (Note 1)
0-255 (unique ID in cycle)
8
.smallcircle. Layer 2 Frame Start (Note 1)
0-255 (Layer 2 frame identifier)
8
______________________________________
Note 1
N instances of these two elements are sent consecutively.
SMS data may span several SMS frames, but the flags TF enable interruption of the sub-channel cycles (cycle clearing). For example, after a flag TF, the mobile station assumes that the next sub-channel is the start of the new cycle. There are two ways to change the data provided on the broadcast SMS: changing the Layer 3 messages within the SMS (messages may be added and/or deleted from any position in the cycle), and changing the structure of the sub-channels. The SMS Message IDs, of which there are a set of 256, and their associated Layer 2 Frame Starts comprise a list of all messages appearing in an SMS frame. SMS Message IDs are unique for each SMS frame and the whole set of 256 values is used before the set begins to be used again in order to aid the mobile in searching for changed message(s) and in avoiding reading messages that have not changed. A Layer 2 Frame Start information element is provided to point to the start of the Layer 2 frame in which the associated SMS message begins (the message does not have to begin at the start of the Layer 2 frame). A description of message delivery is provided in the description of the S-BCCH Layer 2 Protocol given below. In the example shown in the table below, four messages make up SMS frame 1, and it may be assumed that only one slot in each superframe is dedicated to S-BCCH. (Since it is currently preferred that each SMS frame include twenty-four superframes, there are twenty-four slots in each SMS frame.)
______________________________________
Previous SMS New SMS
Frame 1 Header Frame 1 Reader
______________________________________
Number of sub-channels 3
Number of sub-channels 3
Sub-channel number 1
Sub-channel number 1
Length of sub-ch. cycle 2
Length of sub-ch. cycle 2
Phase of sub-ch. cycle 1
Phase of sub-ch. cycle 1
Number of SMS messages (N) 4
Number of SMS messages (N) 5
.smallcircle.1 SMS message ID 1
.smallcircle.1 SMS message ID 1
.smallcircle.1 Layer 2 Frame Start 1
.smallcircle.1 Layer 2 Frame Start 1
.smallcircle.2 SMS message ID 2
.smallcircle.2 SMS message ID 2
.smallcircle.2 Layer 2 Frame Start 2
.smallcircle.2 Layer 2 Frame Start 2
.smallcircle.3 SMS message ID 3
.smallcircle.4 SMS message ID 4
.smallcircle.3 Layer 2 Frame Start 2
.smallcircle.4 Layer 2 Frame Start 2
.smallcircle.4 SMS message ID 4
.smallcircle.5 SMS message ID 5
.smallcircle.4 Layer 2 Frame Start 3
.smallcircle.5 Layer 2 Frame Start 3
.smallcircle.6 SMS message ID 6
.smallcircle.6 Layer 2 Frame Start 3
______________________________________
In the table above, the mobile is assumed to be monitoring the SPACH when the TF toggles to indicate a change in the S-BCCH. The mobile knows from its own internal superframe count where the start of the SMS frame is, and it can determine that SMS sub-channel three is currently being broadcast by reading the SMS header and that the TF points to a change in SMS sub-channel one. When SMS sub-channel one begins, the mobile reads the SMS header. It determines that message 3 is removed; that the position of message 4 has changed (but the message ID is the same so the mobile does not need to re-read this message); and that new messages 5 and 6 have been added and must be read. The mobile may skip the appropriate number of Layer 2 frames to read the new messages. S-BCCH LAYER 2 PROTOCOL The S-BCCH Layer 2 protocol is used when a TDMA burst carries S-BCCH information. Each S-BCCH Layer 2 protocol frame is constructed to fit in a 125-bit envelope. An additional five bits are reserved for use as tail bits, which are the last bits sent to the channel coder, resulting in a total of 130 bits of Layer 2 information carried within each S-BCCH slot. As noted above, the Layer 2 protocol for S-BCCH operation supports only unacknowledged operation. Several different S-BCCH Layer 2 frames which support this exemplary SMS embodiment are shown in FIGS. 13a, 13b, 13c. FIG. 13a shows a mandatory minimum S-BCCH BEGIN frame and FIG. 13b shows another S-BCCH BEGIN Frame used when two Layer 3 messages are included in the frame with the second Layer 3 message being continued in a following frame. The BEGIN frames are used for starting the delivery of one or more Layer 3 messages on the S-BCCH, and it is currently preferred that an S-BCCH BEGIN frame be used as the first frame of the S-BCCH cycle. If the first Layer 3 message is shorter than one S-BCCH frame, a begin/end indicator BE is added to the end of the L3DATA field as shown to indicate whether or not an additional Layer 3 message is started within the BEGIN frame. As shown in FIG. 13a, if the BE indicator is set to indicate "END", the rest of the BEGIN frame is padded with FILLER, e.g., zeroes. As shown in FIG. 13b, if the BE indicator is set to indicate "BEGIN", a new Layer 3 message is started in the BEGIN frame. If the L3DATA field ends on an S-BCCH frame boundary, the BE indicator is not included in the frame; an "END" indication is implied. If the L3DATA field ends with less than nine bits remaining in the S-BCCH frame, the BE indicator is set to "END", and the rest of the frame is padded with FILLER. FIG. 13c shows an S-BCCH CONTINUE Frame (mandatory minimum), which is used for continuation of a Layer 3 message that was too long to fit into the previous frame. The continuation length indicator CLI field indicates how many bits of the CONTINUE frame belong to the continued message, and thus the preceding Layer 3 message may have to be padded with FILLER. If the BE indicator is set to "END", the rest of the CONTINUE frame is padded with FILLER. If the BE indicator is set to "BEGIN", a new Layer 3 message is started in the CONTINUE frame. If the L3DATA field ends on an S-BCCH frame boundary, the BE indicator is not included in the frame; an "END" indication is implied. If the L3DATA field ends with less than nine bits remaining in the S-BCCH frame, the BE indicator is set to "END", and the rest of the frame is padded with FILLER. The CLI makes it possible for mobile stations to receive any message starting in a continuation frame, even if the preceding logical frame was not received. The following table summarizes the fields included in the S-BCCH Layer 2 protocol frames.
______________________________________
Field Name Bit Length
Values
______________________________________
SCS = S-BCCH Cycle Start
1 0 = Not the start of an
S-BCCH cycle
1 = Start of an S-BCCH
cycle
BC = Begin/Continue
1 0 = Begin
1 = Continue
CLI = Continuation Length
7 Number of bits remaining in
Indicator previous Layer 3 message.
L3LI = Layer 3 Length
8 Variable length Layer 3
Indicator messages supported up to a
maximum of 255 octets
L3DATA = Layer 3 Data
Variable Contains a portion (some or
all) of the Layer 3 message
having an overall length
indicated by L3LI. The
portion of this field not used
to carry Layer 3 data is filled
with zeroes.
BE = Begin/End 1 0 = Beginning
1 = End
FILLER = Burst Filler
Variable All filler bits are set zero
CRC = Cyclic Redundancy
16 Same generator polynomial as
Code IS-54B. The nominal DVCC
is applied in the calculation
of CRC for each S-BCCH
Layer 2 frame.
______________________________________
Similar logical frames can be defined for the F-BCCH and E-BCCH, as described in U.S. patent application Ser. No. 08/147,254 for example, but these are beyond the scope of this application. LAYER 3 MESSAGES The S-BCCH Layer 3 messages that are mapped to the Layer 2 frames are described below. In all messages shown in tabular form below, the information elements in the top rows of the tables are preferably the first elements to be delivered to Layer 2. In the information elements, the most significant bit (the left-most bit in the tables) is the first bit to be delivered to Layer 2. The information elements are described in alphabetical order after the description of the messages below. There are two types of S-BCCH messages used for SMS broadcast: SMS frame header messages; and SMS non-header messages, which are those used to transfer the actual messages to the mobile stations. The SMS frame header messages describe the structure of the SMS sub-channel, and are provided in the first slot of each SMS frame. The format of a suitable SMS frame header message is described in the following table.
______________________________________
Information Element Type Bit Length
______________________________________
Message Type M 8
Number of Sub-channels
M 2
Sub-channel Number M 2
Phase Length of Sub-ch. Cycle
M 6
Phase Number of Sub-ch. Cycle
M 6
Number of SMS Messages (N)
M 6
.smallcircle. SMS Message ID (Note 1)
M 8
.smallcircle. Layer 2 Frame Start (Note 1)
M 8
Total = 46
______________________________________
NOTE 1:
N instances of these two elements are sent consecutively.
The format of a suitable SMS non-header, broadcast message is as follows:
______________________________________
Information Element
Type Bit Length
______________________________________
Message Type M 8
SMS Message ID M 8
Text Message Data Unit
M N*8
N max. = 253
______________________________________
In one aspect of Applicants' invention, SMS messages may be encrypted in a way that supports different classes of message service, much like cable television systems distinguish premium classes of service from a basic service class by scrambling or otherwise protecting the premium programming. For example, three classes might be provided as follows: a basic class in which any subscriber paying an appropriate fee would be able to de-crypt some of the SMS broadcast messages, such as product advertisements, weather and vehicle traffic announcements; a higher class in which a subscriber paying a higher fee would be able to de-crypt the SMS broadcast messages available to the basic class and additional messages, such as news items; and a highest class in which a subscriber paying a highest fee would be able to de-crypt all of the SMS broadcast messages, including financial quotations and higher-value items of information. The de-cryption of the SMS messages could be carried out by the processing units in the mobile stations according to any of a wide variety of cryptographic techniques. Preferably, each broadcast message would include as an attribute an indicator for determining which encryption key or algorithm should be used to decode the respective message. Such attributes might be included in the SMS frame headers, and the encryption keys or algorithms could be sent to the mobiles over the air or entered directly, via a "smart card", for example. As an alternative, the sub-channels could be individually encrypted, so that broadcast SMS messages included in the time slots of one of the SMS sub-channels are encrypted according to one encryption method and the broadcast SMS messages included in the time slots of another SMS sub-channel are encrypted according to a another encryption method. INFORMATION ELEMENT DESCRIPTION A few coding rules apply to the information element descriptions. For example, information elements of the type "flag" have values of 0 to indicate "disable", or "off", or "false", and values of 1 to indicate "enable", or "on", or "true". Also, certain BCCH fields do NOT trigger a transition in the BCCH change flag in the SPACH; those fields are designated as non-critical, or "NC". Information elements of the type "transition" are modulo-1 counters for indicating changes in current status. The channel number is coded in accordance with the IS-54B standard, unless otherwise noted. All lengths are specified in bits, unless otherwise noted. Layer 2 Frame Start This variable indicates the number of slots from the start of the SMS sub-channel cycle to the beginning of the SMS message, which may not begin in the indicated SMS slot but may be contained in an end/begin burst used to start delivery of this message. Message Type This 8-bit information element identifies the function of the message being sent. The message types are coded as follows:
______________________________________
S-BCCH Messages Code (binary-hex)
______________________________________
Broadcast Information Message
0010 0111-27
______________________________________
Number of SMS Messages This variable indicates the number of broadcast SMS messages in this SMS frame (1 plus the value in this field). Number of Sub-channels This variable indicates the number of SMS sub-channels being used by this DCCH (1 plus the value in this field). Phase Length of Sub-ch. Cycle This variable indicates the number of SMS frames that make up one cycle (1 plus the value in this field). Phase Number of Sub-ch. Cycle This variable indicates which SMS frame in the cycle is currently being broadcast. Sub-channel Number This variable indicates which sub-channel is currently being broadcast. According to another exemplary embodiment, the amount of bandwidth per sub-channel (i.e., the periodicity at which each sub-channel is transmitted) and the ordering of sub-channels is dynamic to provide additional flexibility to broadcast SMS systems. Although the term "sub-channels" is used herein, those skilled in the art will appreciate that any other term or phrase which connotes logical grouping of SMS messages could be used to describe these groupings of the present invention. Moreover, according to this exemplary embodiment, a greater number of SMS sub-channels, e.g., 8, 16, 32, 64, etc., can be supported than the four sub-channels used to illustrate the previous exemplary embodiment. For the purposes of illustration, rather than limitation, an example will be provided wherein up to 32 S-BCCH sub-channels are supported. According to this exemplary embodiment, a particular subset of message attributes is associated with each sub-channel rather than broadcasting messages having any set of attributes on any sub-channel, as in the previous exemplary embodiment. The particular order in (and periodicity at) which these sub-channels are transmitted can be varied by the system operator according to, for example, the number of messages which have the attribute(s) associated with each sub-channel. The system can broadcast messages using associated with a sub-channel on, for example, a number of contiguous S-BCCH time slots, which number may vary for each sub-channel. The broadcasting of a sub-channel may, however, be interrupted by the system in order to broadcast messages on sub-channels 0 and 1 for reasons that will become apparent. Since sub-channeling according to this exemplary embodiment does not have a fixed, time multiplexed format such as that provided in the earlier embodiment, a different mechanism (i.e., other than an SMS frame header) is used to provide overhead information. In this example overhead information including, for example, the total number of sub-channels currently activated, the message encryption algorithm associated with each sub-channel (if any), the user group associated with each sub-channel (if any), and other S-BCCH attributes described below, is provided on sub-channel 0. Channel 0 is dedicated to this overhead function so that mobile stations will know where to find this information. When a cycle of sub-channel 0 information is to be sent by the system (e.g., broadcast from a base station), it can be started in a first S-BCCH time slot coincident with a hyperframe counter value of zero. For example, sub-channel 0 can be broadcast at least once every 12*N hyperframes (N=1,2,3 . . . ) or when otherwise desired by a system operator. Once started, the broadcast of sub-channel 0 should be completed without interruption using consecutive S-BCCH time slots. Sub-channel 1 is dedicated, according to this exemplary embodiment, to the provision of messages associated with other sub-channels (i.e., sub-channels 2-31 in this example) that have recently been changed or added. Typically, deleted messages are of no interest to mobile stations, however, those skilled in the art will recognize that the present invention can be readily extended to provide an indication to mobile units that a message has been deleted in a manner similar to that described herein for changed messages and added messages. The broadcast of sub-channel 1 by the system may commence after the completion of any sub-channel or by interrupting a sub-channel (other than sub-channels 0 or 1). For example, it may be considered desirable by a system operator to begin increase the periodicity of transmission of sub-channel 1 after the transmission of sub-channel 0 in which a change or changes have been indicated. Once the broadcast of sub-channel 1 has begun, it should be completed without interruption using consecutive S-BCCH time slots. By reading sub-channel 1, a mobile station will be able to quickly access changed or added messages of interest. From the mobile station's perspective, upon camping on a DCCH the mobile can, for example, read sub-channel 0 to determine if it needs to acquire the S-BCCH information broadcast thereon that is associated with that particular DCCH. For example, after cell reselection, the mobile may have camped on a DCCH whose S-BCCH has a different structure in terms of the number of sub-channels currently activated, the user groups and/or encryption techniques associated with each sub-channel, etc. In such a case, the mobile would need this information in order to perform additional SMS activities supported by that DCCH. The selective acquisition of S-BCCH information is supported by, for example, a broadcast domain indicator provided as part of a Layer 3 message transmitted on sub-channel 0. This broadcast domain indicator is discussed in more detail below. For example, a mobile station reading sub-channel 0 may determine that it has locked to a DCCH associated with the same broadcast domain under which that mobile was previously operating, i.e., if the broadcast domain value read by the mobile station is the same as that previously read and stored, but where some changes have occurred in the S-BCCH information. In such a situation, the mobile station may need to read only the S-BCCH information which has changed since certain sub-channeling structure will be common to cells which support the same broadcast domain. More detailed examples describing of the interaction between a mobile station reading sub-channel 0 and the broadcast domain indicator will be provided after a description of the Layer 2 protocols and Layer 3 messages. While in the process of acquiring the S-BCCH information broadcast on sub-channel 0, this information could be changed by the system, e.g., to add a new sub-channel to handle messages sent to a new user group and/or using a different encryption algorithm. Similarly, the S-BCCH information associated with a DCCH can change after it is acquired by a mobile station. In either case a Layer 2 change indication is sent to the mobile which responds by reading sub-channel 0. For example, a change notification bit can be placed in the SPACH header and used to notify mobile stations of changes in the content of the S-BCCH information. For a detailed description of the SPACH and SPACH header, the interested reader is referred to U.S. patent application Ser. No. 08/331,816 entitled "Layer 2 Protocol in Cellular Communication System" filed on Oct. 31, 1994, which disclosure is incorporated here by reference. According to this exemplary embodiment, and as distinguished from the transition flags TF(i), change indication is generic in the sense that the particular sub-channel or sub-channels which have been modified are not identified in the Layer 2 change notification. Instead, the affected mobile stations will read sub-channel 0 to determine the specific sub-channel or sub-channels which have been modified. In this way the modified S-BCCH information can be sent to the mobile stations beginning in the hyperframe immediately following the hyperframe in which the Layer 2 change indication is provided. The exemplary Layer 2 protocol defined below supports S-BCCH operation to allow a mobile station to uniquely determine the start and end of a sub-channel and to begin reading a sub-channel starting with any Layer 2 frame belonging to that sub-channel. According to this exemplary embodiment, each sub-channel is sent using up to 256 Layer 2 frames. Of course, those skilled in the art will appreciate that other sub-channel capacities can be used without departing from the spirit of the present invention. An exemplary 256 Layer 2 frame sub-channel would, however, provide about 10 maximum length (i.e., 255 octets) Layer 3 messages per sub-channel or about 25 SMS messages per S-BCCH sub-channel assuming an average of 100 octets of data per message. In this exemplary embodiment, a Layer 3 message qualifier can be used to identifies up to, for example, 256 distinct S-BCCH Payload messages over all of the SMS "traffic" sub-channels 2-31. Additional S-BCCH messages can be identified by creating other types of Layer 3 messages and pairing the associated Layer 3 message type with the Layer 3 message qualifier e.g., 256 different S-BCCH messages per pair. Having provided an overview of message delivery in accordance with this second exemplary SMS embodiment, exemplary Layer 2 and Layer 3 protocols for supporting these functions will now be described. S-BCCH LAYER 2 PROTOCOL (SECOND EXEMPLARY EMBODIMENT) The S-BCCH Layer 2 protocol is used when a TDMA slot is used to carry S-BCCH information. The S-BCCH protocol allows for supporting up to a maximum of 32 distinct S-BCCH sub-channels. The set of layer 3 messages comprising a S-BCCH sub-channel is sent using up to 256 S-BCCH layer 2 protocol frames. Each S-BCCH Layer 2 protocol frame can be constructed to fit within a 125 bit envelope. An additional 5 bits are reserved for use as tail bits resulting in a total of 130 bits of information carried within each S-BCCH slot. The Layer 2 protocol defined in this exemplary embodiment for S-BCCH operation supports only unacknowledged operation. FIGS. 14(a)-14(e) provide examples of Layer 2 S-BCCH frames. The BEGIN frame is used for starting the delivery of one or more Layer 3 messages on any given sub-channel of the S-BCCH. The Layer 3 that constitutes the opening message of a full cycle of S-BCCH information for any sub-channel shall be transmitted starting with a BEGIN FRAME and shall occupy the first L3DATA field included in the BEGIN frame should more than one L3DATA field be present therein. Exemplary rules for the placement of Layer 3 messages within a BEGIN frame are as follows. If a Layer 3 message fits entirely within the L3DATA field of a BEGIN frame with 9 or more bits remaining in the frame, the Begin Indicator (BI) is included immediately after the L3DATA field to indicate whether or not an additional Layer 3 message is started within the frame. If BI=0, no other Layer 3 message is started and the rest of the frame is padded with FILLER. If BI=1 a L3LI field is included immediately after the BI field. The L3LI field is then followed by another L3DATA field containing a portion of the new Layer 3 message determined by the number of bits remaining in the frame. If, on the other hand, a Layer 3 message fits entirely within the L3DATA field of a BEGIN frame with from 1 to 8 bits remaining in the frame and another Layer 3 message is to be sent, BI=0 is included immediately after the L3DATA field. The rest of the frame is then padded with FILLER and the next Layer 3 message is sent starting with another BEGIN frame. If a Layer 3 message fits entirely within the L3DATA field of a BEGIN frame with from 1 to 8 bits remaining in the frame and no other Layer 3 message is to be sent, BI=0 is included immediately after the L3DATA field and the rest of the frame is padded with FILLER. If a Layer 3 message fits entirely within the L3DATA field of a BEGIN frame with no bits remaining, the BI field is not present and the end of the Layer 3 message is implied. This case is exemplified in FIG. 14a. Lastly, if a Layer 3 message does not fit entirely within the L3DATA field of a BEGIN frame, it is completed using as many CONTINUE frames as necessary. The other fields illustrated in FIG. 14a are described in Table 1 below. The CONTINUE frame is used whenever a Layer 3 message cannot be completed within the previous S-BCCH Layer 2 frame. Exemplary CONTINUE frames are illustrated in FIGS. 14b-14d. The CLI field indicates how many bits of the CONTINUE frame belong to the continued Layer 3 message. This in turn allows for mobile stations to receive a portion of a new message which may be present in the CONTINUE frame following the L3DATA field used to complete a message continued from the previous frame. Exemplary rules for the placement of Layer 3 message information within a CONTINUE frame are as follows. If the CLI field indicates that the remainder of a continued Layer 3 message fits entirely within the CONTINUE frame with 9 or more bits remaining in the frame, the Begin Indicator (BI) is included immediately after the L3DATA field to indicate whether or not an additional Layer 3 message is started within the frame. For example, if BI=0 no other Layer 3 message is started and the rest of the frame is padded with FILLER. This case is illustrated as FIG. 14b. If BI=1, then an L3LI field is included immediately after the BI field. The L3LI field is then followed by another L3DATA field containing a portion of the new Layer 3 message. The length of the portion of the new Layer 3 message in the second L3DATA field is determined by the number of bits remaining in the frame. This case is illustrated in FIG. 14c. If CLI indicates that the remainder of a continued Layer 3 message fits entirely within the CONTINUE frame with from 1 to 8 bits remaining in the frame and another Layer 3 message is to be sent, BI=0 is included immediately after the L3DATA field. The rest of the frame is padded with FILLER and the next Layer 3 message is sent starting with another BEGIN frame. This case is also exemplified by the format of FIG. 14b. If CLI indicates that the remainder of a continued Layer 3 message fits entirely within the CONTINUE frame with from 1 to 8 bits remaining in the frame and no other Layer 3 message is to be sent, BI=0 is included immediately after the L3DATA and the rest of the frame is padded with FILLER. If CLI indicates that the entire CONTINUE frame contains information belonging to a continued Layer 3 message, the BI field is not present in the frame. This is illustrated in FIG. 14d. A continued Layer 3 message is completed using as many CONTINUE frames as necessary. The following table summarizes the exemplary fields provided in these S-BCCH Layer 2 frames according to this exemplary embodiment.
TABLE 1
______________________________________
S-BCCH Layer 2 Protocol Field Summary
LENGTH
FIELD NAME (Bits) VALUES
______________________________________
BC = Begin/Continue
1 Identifies the type of L2 frame
(0 = Begin, 1 = Continue)
SID = Sub-channel ID
5 Uniquely identifies the sub-
channel that a L2 frame belongs
to (0..31).
FDC = Frame Down
8 Uniquely identifies a Layer 2
Counter frame used in sending a cycle
of sub-channel information
(0..255).
SSI = Sub-channel Start
1 Indicates whether or not a L2
Indicator frame is the first frame used in
sending a cycle of sub-channel
information (0 = No, 1 = Yes).
SCN = S-BCCH Change
1 Transitions whenever there is a
Notification change in the content of S-
BCCH information. A mobile
station responds by reading S-
BCCH information on sub-
channel 0.
CLI = Continuation
7 Number of bits in the current
Length Indicator L2 frame used to carry
information from a previously
initiated L3 message.
L3LI = Layer 3 Length
8 Variable length Layer 3
indicator messages supported from 0 up
to a maximum of 255 octets.
L3DATA = Layer 3 Data
Variable Contains a portion (some or all)
of the Layer 3 message having
an overall length as indicated
by L3LI. The portion of this
field not used to carry Layer 3
information is filled with zeros.
BI = Begin Indicator
1 0 = No additional Layer 3
message present
1 = Additional Layer 3 message
present
FILLER = Burst Filler
Variable All filler bits are set to zero.
CRC = Cycle Redundancy
16 Same generator polynomial as
Code IS-54B. The nominal DVCC is
applied in the calculation of
CRC for each S-BCCH Layer 2
frame.
______________________________________
An S-BCCH Request primitive can be provided to transfer Layer 3 messages to be sent on the S-BCCH to Layer 2. For example, the S-BCCH Request primitive can include the following protocol elements: (1) a Layer 3 message (examples below); (2) a Layer 3 Length Indicator (L3LI) providing the length of the Layer 3 message (e.g., in octets); and (3) a sub-channel ID which identifies the sub-channel that the Layer 3 message is associated with. LAYER 3 MESSAGES (SECOND EXEMPLARY EMBODIMENT) Exemplary Layer 3 messages which can be mapped to Layer 2, e.g., using the primitive described above are set forth below. As in the description of the previous exemplary embodiment, the information elements in the top rows of tables can be the first elements delivered to Layer 2. In the information elements, the most significant (i.e., leftmost) bit is the first bit to be delivered to Layer 2. The information elements are described in alphabetical order after the description of the message below. A Sub-channel Configuration message is sent on sub-channel 0 to define the format of supported channels. An exemplary format for the Sub-channel Configuration message is illustrated below.
______________________________________
Information Element
Reference Type Length
______________________________________
Protocol Discriminator M 2
Message Type M 6
Sub-channel Count (N) M 5
Sub-channel Info (Note 1) O 13-*
______________________________________
Note 1:
N instances of this information element are included up to a maximum
number of supported "traffic" subchannels, e.g., 30.
The Sub-channel Count information element identifies the number of sub-channels used in support of sending S-BCCH information. In this exemplary embodiment five bits are provided to support the 32 sub-channels. Of course more or fewer bits could be provided to represent this value if more or fewer sub-channels are to be supported, respectively. The Sub-Channel Info information element identifies the attributes of supported S-BCCH sub-channels. An exemplary format for this information element is shown below.
______________________________________
Field Length
______________________________________
Sub-channel ID (Note 1)
5
MEA 3
MEK 3
Wildcard Indicator
1
Broadcast Mode 1
User Group Type (Note 2)
0, 2
User Group ID (Note 2)
0, 20, 24, 34 or 50
______________________________________
Note 1:
Subchannels 0 and 1 are defined implicitly and therefore need not be
explicitly defined.
Note 2:
Only present if the Broadcast Mode indicates User Group ID specific
broadcast.
Each of the fields of the Sub-channel Info information element and the attributes which they describe are set forth in more detail below. The Sub-channel ID field identifies a specific S-BCCH sub-channel (0 . . . 31) associated with each of the other parameters in the information element. This field can be used by a mobile station as an index by which the mobile station can update its information as to the structure of certain sub-channels as needed, e.g., newly added sub-channels. The MEA and MEK fields identify the encryption technique (if any) associated with the particular sub-channel identified by the sub-channel ID field. Encryption can, for example, be one of the message attributes upon which the grouping of messages into logical sub-channels can be based. This technique is illustrated by way of the flow chart in FIG. 15. Therein, at steps 1500 and 1502, message attributes are identified and selected for subsequent use in grouping messages (step 1504). These groups of messages are then transmitted on their respective subchannel (step 1506). The MEA field can, for example, be coded as follows.
______________________________________
Value Function
______________________________________
000 No Message Encryption
001 Message Encryption Algorithm A
______________________________________
All other values are reserved
The MEK field can, for example, be coded as follows.
______________________________________
Value Function
______________________________________
001 Message Encryption Key A
______________________________________
All other values are reserved
The combination of both an MEA and MEK can be used to provide, for example, different levels of service to publicly available channels. For example, different encryption algorithms could be associated with each encryption key to provide different levels of access to information. Thus, a Bronze class message group could be associated with a first encryption algorithm and an encryption key, a Silver class message group (i.e., sub-channel) could be associated with a second encryption algorithm and that encryption key, and a Gold class message group could be associated with a third encryption algorithm and that encryption key. The Wildcard Indicator field indicates whether or not the sub-channel identified by the sub-channel ID field belongs to the broadcast domain. Each broadcast domain (e.g., each system operator) may have certain standard or common sub-channels. Other sub-channels, which are not common to a broadcast domain, may nonetheless be broadcast by the system. The mobile station learns of these non-standard sub-channels by reading the Wildcard Indicator. The Wildcard Indicator field can, for example, be coded as follows.
______________________________________
Value Function
______________________________________
0 Standard Sub-channel
(part of Broadcast Domain)
1 Wildcard Sub-channel
(not part of Broadcast Domain)
______________________________________
The Broadcast Mode field indicates whether or not the sub-channel identified in sub-channel ID field is restricted to a particular user group. The Broadcast Mode field can, for example, be coded as follows.
______________________________________
Value Function
______________________________________
0 Unrestricted Broadcast
1 User Group ID Specific Broadcast
______________________________________
The User Group Type and User Group ID fields specify the user group to which this sub-channel is restricted if the appropriate value is set in the Broadcast Mode field. The User Group Type field can, for example, be coded as follows.
______________________________________
Value Function
______________________________________
00 20-bit Local UGID
01 24-bit SOC UGID
10 34-bit National UGID
11 50-bit International UGID
______________________________________
The User Group Type field indicates, for example, how many bits to expect in the User Group ID field, which identifies the User Group to which an S-BCCH sub-channel has been allocated. The Sub-channel Change Summary message is also sent on S-BCCH sub-channel 0 to indicate the nature of changes made to S-BCCH information. An exemplary format for this message is set forth below.
______________________________________
Information Element
Reference Type Length
______________________________________
Protocol Discriminator M 2
Message Type M 6
Broadcast Domain ID M 8
Change Indicator Map M 32
Change Acquisition Map M 32
______________________________________
The Broadcast Domain ID information element is used to identify, for example, a system operator code (SOC) specific S-BCCH broadcast area as described above. More specifically, the Broadcast Domain ID provides an indication to a mobile station of whether certain commonalities expected within a broadcast domain are available to that mobile station when the mobile station locks on to another DCCH. For example, adjacent DCCHs that have the same SOC and that send the same set of S-BCCH information on the same standard sub-channels shall use the same Broadcast Domain ID value. The Change Indicator Map information element is used to provide change indication information on a per sub-channel basis. The leftmost bit in this map corresponds to sub-channel 31 and the rightmost bit corresponds to sub-channel 0. Whenever there is a modification to the content of a sub-channel (other than a deletion) the corresponding bit position in this map is toggled. Mobile stations need only proceed to acquire the new S-BCCH information for the modified sub-channels that are of interest, e.g., according to the Change Acquisition Map element described below. The Change Acquisition Map information element is use to provide change acquisition information on a per sub-channel basis. The leftmost bit in this map corresponds to sub-channel 31 and the rightmost bit corresponds to sub-channel 0. Whenever there is a modification to the content of a sub-channel (other than a deletion) the corresponding bit position in this map is used to inform mobile stations how to acquire the new information as follows. When a bit of this map is set to 0, then mobile stations that have previously read the newly modified sub-channel associated with that bit shall acquire the new information by reading sub-channel 1. Mobile stations that are in the process of reading or have never read the newly modified sub-channel shall acquire the new information by (re-)reading a full cycle of information from the modified sub-channel. When a bit of this map is set to 1, mobile stations shall acquire the new information by reading a full cycle of information from the newly modified sub-channel. The S-BCCH Payload message is sent on sub-channels 1 through 31 in order to provide the Layer 3 messages specific to S-BCCH operation and can, for example, have the following format.
______________________________________
Information Element
Reference Type Length
______________________________________
Protocol Discriminator M 2
Message Type M 6
Message Type Qualifier M 8
Other Data (TBD) TBD TBD
______________________________________
The Message Type information element identifies the function of the message, e.g., an S-BCCH Payload message. The Message Type Qualifier information element is used to identify up to 256 distinct S-BCCH messages. For example:
______________________________________
Value Function
______________________________________
0000 0000 Casino Clips
0000 0001 Road Report
0000 0010 Rugby News
______________________________________
All other values are reserved.
The Other Data (TBD) field can be used to provide, e.g., higher layer protocols such as how long a message should be retained for retransmission on a sub-channel. The Sub-channel Delimiter message can be sent on sub-channel 1 to delimit groups of S-BCCH Payload messages, also sent on sub-channel 1, that are associated with specific sub-channels. This allows mobile stations to determine the nominal sub-channels that each S-BCCH Payload message is associated with. The Sub-channel Delimiter message can, for example, have the following format.
______________________________________
Information Element
Reference Type Length
______________________________________
Protocol Discriminator M 2
Message Type M 6
Sub-channel ID M 5
______________________________________
Having described exemplary Layer 3 messages, the operation of a mobile station in such a system will now be described by way of several examples. As mentioned above, a mobile station that acquires a new DCCH (e.g., by cell reselection) shall perform an S-BCCH update by first reading sub-channel 0 to determine if the S-BCCH information associated with this DCCH is different. For example, assume that the mobile station has travelled to a cell whose DCCH is associated with another broadcast domain (e.g., a different system operator). Under these circumstances, the mobile station will read a full cycle of information on all sub-channels determined to be of interest according to subchannel 0 information. Sub-channels of interest can, for example, include those sub-channels whose encryption techniques match those which the mobile station can decrypt and/or those sub-channels accessible to a common user group supported by the mobile station. As another example, consider a mobile station which is informed, by a change in the notification flag found in the SPACH header, that the contents of the S-BCCH have changed. Suppose, for this example, that the change constitutes the addition of a new sub-channel. The mobile station will then read sub-channel 0. If it first receives a Subchannel Change Summary message, the mobile station will learn, from the setting of a bit in the Change Indicator Map information element, that a new sub-channel has been added. However, the mobile station will not know, based on this message, whether or not this is a sub-channel of interest, since the Subchannel Change Summary message does not provide an indication of the sub-channel attributes associated with the newly added sub-channel. Accordingly, the mobile will read a Subchannel configuration message to determine if it is interested in the new sub-channel and read a cycle of that sub-channel as desired. As another example, consider a mobile station that is informed of a change in S-BCCH information via the S-BCCH change notification flag carried in the SPACH header. Suppose, for this example, that the change constitutes the modification of a single message sent on a specific sub-channel of interest to the mobile station. The mobile station responds to the change notification by first reading sub-channel 0 to acquire the Sub-channel Change Summary message. The Change Indicator Map information element contained within this message identifies that only a single sub-channel has changed. A bit position in the Change Indicator Map information element and its corresponding value serves to uniquely identify the changed sub-channel. The Change Acquisition Map information element, also contained within this message, indicates how the changed information is to be acquired for the changed sub-channel identified. For this example, assume that the bit position in the Change Acquisition Map information element corresponding to the changed sub-channel indicates that sub-channel 1 should be read to acquire the changes associated with the changed sub-channel. The mobile station then proceeds to read a full set of information sent on sub-channel 1 (in this example only a single S-BCCH Payload message since only one sub-channel has changed) and updates its S-BCCH information accordingly. Although the present invention has been described in terms of attributes such as types of encryption and user group assignment, those skilled in the art will appreciate that other types of attributes can be added or substituted for those described herein. Moreover, other broadcast SMS embodiments will also be apparent to those skilled in the art as being within the scope of the present invention without a detailed description thereof. For example, sub-channel 1 need not be dedicated to carry change information. Instead, additional segmentation can be provided at Layer 2 whereby strings of Layer 2 frames are also defined to allow guaranteed delivery of these distinct strings without interruption (unless aborted) while still allowing for a fast real time response to information change situations. Another technique would be to provide only a single (large) payload sub-channel used for carrying the full set of broadcast information rather than the exemplary sub-channels 2 . . . 32 described above. Changes could still be carried on sub-channel 1 and sub-channel 0 could still contain sub-channel structure and detailed change indication information. Message encryption and user group operation would then be specified on a per BCCH message basis. Moreover, although these illustrative embodiments describe a mobile station that first reads sub-channel 0 upon receiving a change notification, those skilled in the art will appreciate that the mobile station could vary this procedure. For example, sub-channel 1 could be read first by the mobile station to determine which messages have changed. A change flag could be provided on sub-channel 1 to indicate whether or the information on sub-channel 0 has changed, at which point the mobile station could then acquire the S-BCCH information of sub-channel 0. It is, of course, possible to embody the invention in specific forms other than those described above without departing from the spirit of the invention. The embodiments described above are merely illustrative and should not be considered restrictive in any way. The scope of the invention is determined by the following claims, rather than the preceding description, and all variations and equivalents which fall within the scope of the claims are intended to be embraced therein.
|
Same subclass | ||||||||||