4 Broadcast Message Contents
3GPP44.035Broadcast network assistance for Enhanced Observed Time Difference (E-OTD) and Global Positioning System (GPS) positioning methodsGSM/EDGE Location Services (LCS)Release 17TS
This clause describes the LCS Assistance Data messages to be broadcasted in SMSCB message’s content part over CBCH channel using SMSCB DRX service. The rules and contets are described so that SMLC is able to construct the message as well as MS is able to process the received message. The E-OTD Assistance Data message contains RTD and BTS coordinate information and GPS Assistance Data contains GPS Differential Correction data, Emphemeris and Clock Correction Data and Almanac and Other Data.
4.1 E-OTD Assistance Data Broadcast Message
The E-OTD Assistance Data message contents are defined in this clause. The E-OTD Assistance Data message is built so that it has always a fixed length and some of the information elements are scalable according to the amount of neighbours and the amount of sectored channels. The information elements are in the order which is described in subclause 4.1.1 and no spare bits are allowed between elements. The MSB bits of the information elements are presented always first and if boundary of the octet divides the information element then the LSB part of the information element continues in the LSB part of the next octet (figure 1). Example of E-OTD Assistance Data Broadcast Message is in annex B. The channel to broadcast the E-OTD Assistance Data message is CBCH over which the SMSCB DRX service is used. One SMSCB message has fixed information data length of 82 octets and the purpose is always to use the whole fixed length message capacity for the message. MS can identify the LCS SMSCB message with E-OTD Message Identifier declared in 3GPP TS 23.041.
Figure 1: Information element bit mapping to the broadcast message
4.1.1 E-OTD Assistance Data Broadcast Message Content
The Broadcast Assistance Data is a point-to-multipoint message from the GSM Network to the MSs. This message gives assistance data to the MS for performing E-OTD measurements and calculating its own position. It contains the following information elements. The information elements are always in the order described in table 1. The ciphered part of message is end of message and indicated with grey shading in table 1.
Table 1: E-OTD Assistance Data Broadcast Message Content
|
Information element |
Type/Reference |
Presence |
|
Message Structure Definition |
Message Structure Definition 4.1.1.1 |
M |
|
Reference Time |
Reference Time 4.1.1.2 |
M |
|
Ciphering Serial Number |
Ciphering Serial Number 4.1.1.3 |
C |
|
Time Slot Scheme |
Time Slot Scheme 4.1.1.4 |
M |
|
Neighbour Bitmap Definition |
Neighbour BitmapDefinition 4.1.1.5 |
C |
|
Sectored Channels Definition |
Sectored Channels Definition 4.1.1.6 |
C |
|
Sectored Channels BTS ID Definition |
Sectored Channel’s BTS ID Definition 4.1.1.7 |
C |
|
Sectored BTS Sync/Async Definition |
Sectored BTS Sync/Async Definition 4.1.1.8 |
C |
|
51 Multiframe Offset Values |
51 Multiframe Offset Values 4.1.1.9 |
M |
|
BCC Definition |
BCC Definition 4.1.1.10 |
M |
|
RTD Drift Factor Values |
RTD Drift Factor Values 4.1.1.11 |
C |
|
Channel RTD Values |
Channel RTD Values 4.1.1.12 |
C |
|
Serving Cell Location |
Serving Cell Location 4.1.1.13 |
M |
|
Relative Neighbour Location Values |
Relative Neighbour Location Values 4.1.1.14 |
M |
4.1.1.1 Message Structure Definition IE
This IE contains the definition of this broadcast message. The length of this IE is 19 bits and it is mandatory. This IE contains the following bits.
Table 2: Message Structure Definition
|
Bit |
Bit order in field |
Definition |
|
1 |
LSB MSB |
Neighbour List Map (bits 2-0) |
|
2 |
||
|
3 |
||
|
4 |
LSB MSB |
Accuracy Range (bits 2-0) |
|
5 |
||
|
6 |
||
|
7 |
Ciphering Key Flag |
|
|
8 |
Cipher On/Off |
|
|
9 |
Sector Ind |
|
|
10 |
RTD Range |
|
|
11 |
LSB MSB |
RTD Accuracy (bits 1-0) |
|
12 |
||
|
13 |
RTD Drift Factors Present |
|
|
14 |
RTDs Present |
|
|
15 |
LSB MSB |
Number of Neighbours (bits 4-0) |
|
16 |
||
|
17 |
||
|
18 |
||
|
19 |
The first three octets upto bit 3 in octet 3 in the broadcast message’s content part containing the Message Structure Definition IE look always as follows.
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|
Cipher On/Off |
Cipher-ing Key Flag |
Accuracy Range (bits 2-0) |
Neighbour List Map (bits 2-0) |
Octet1 |
||||
|
Number of Neighbours (bits 4-3) |
RTDs Present |
RTD Drift Factors Present |
RTD Accuracy (bits 1-0) |
RTD Range |
Sector Ind |
Octet2 |
||
|
(Next IE) |
Number of Neighbours (bits 2-0) |
Octet3 |
||||||
The definitions of each structure item is declared below:
Neighbour List Map
These bits define in which order the neighbours in the System Information Neighbour List (max 32 neighbours) are reported with the broadcast message.
– The Neighbour List Map will also affect the amount of bits that can be used for Relative Neighbour Location Value definitions.
– This Broadcast Assistance Data message is always referring to the neighbour BTSs included in the System Information Neighbour List which is received in idle state from BCCH. The E-OTD broadcast message does not allow the possibility for delivering assistance data for other BTSs (outside the the System Information Neighbour List.
Table 3: Neighbour List Map
|
2 |
1 |
0 |
Definition |
|
0 |
0 |
0 |
All Neigbours from neighbour list |
|
0 |
0 |
1 |
Even Neighbours from neighbour list |
|
0 |
1 |
0 |
Odd Neighbours from neighbour list |
|
0 |
1 |
1 |
1st & 1st+n*3 |
|
1 |
0 |
0 |
2nd & 2nd+n*3 |
|
1 |
0 |
1 |
3rd & 3rd+n*3 |
|
1 |
1 |
0 |
Neighbour Bitmap Definition |
|
1 |
1 |
1 |
Spare |
– All Neighbours means all the neighbours from System Information Neighbour list (max 32 neighbours) are reported in this broadcast message (1 broadcast message).
– Even/Odd neighbours from neighbour list means the even/odd list entries in the System Information Neighbour List are reported in this broadcast message (two broadcast messages needed).
– 1st & 1st+ n*3 means that 1st, 4th, 7th, 10th, …, 31st (max 11 neighbours) will be reported in this broadcast message (1/3 of total broadcast).
– 2nd & 2nd+n*3 means that 2nd, 5th, 8th, 11th, …, 32nd (max 11 neighbours) will be reported in this broadcast message (2/3 of total broadcast).
– 3rd & 3rd+n*3 means that 3rd, 6th, 9th, 12th, …, 30th (max 10 neighbours) will be reported in this broadcast message (3/3 of total broadcast).
– The 1st & 1st+n*3, 2nd & 2nd+n*3 and 3rd & 3rd+n*3 means total 3 broadcast messages.
– Neighbour Bitmap Definition will define which neighbours are included into this broadcast message, see subclause 4.1.1.5.
Accuracy Range
The accuracy range declares the accuracy of the values in the Relative Neigbour Location Value IE. The accuracy range has the following information.
Table 4: Accuracy Range
|
2 |
1 |
0 |
Definition |
|
0 |
0 |
0 |
5 km |
|
0 |
0 |
1 |
10 km |
|
0 |
1 |
0 |
15 km |
|
0 |
1 |
1 |
20 km |
|
1 |
0 |
0 |
30 km |
|
1 |
0 |
1 |
45 km |
|
1 |
1 |
0 |
60 km |
|
1 |
1 |
1 |
120 km |
For example if there are 15 bits (1 sign bit and 14 value bits) reserved for Relative Neighbour North or East Value and the accuracy range is defined to be 20 km, then resolution of Relative Neighbour North or East Value is 0.6 m.
Ciphering Key Flag
The MS gets two (2) deciphering keys always with location update, a deciphering key that is time stamped to be current one and deciphering key that time stamped to be next one. Thus the MS has always two deciphering keys in memory. With this Ciphering Key Flag in this broadcast message the MS knows whether to use current/next deciphering key for deciphering the received broadcast message. The MS shall interpret this IE as follows:
– Ciphering Key Flag(previous message) = Ciphering Key Flag(this message) => Deciphering Key not changed.
– Ciphering Key Flag(previous message) <> Cipher Key Flag(this message) => Deciphering Key changed.
Cipher On/Off
This bit indicates whether this broadcast message has been ciphered or not. The RTD Drift Factor Values IE, Channel RTD Values IE, Serving Cell Location IE and Relative Neighbour Location Values IE will be ciphered if ciphering is active.
– ‘0’ Ciphering Off.
– ‘1’ Ciphering On.
Sector Ind
This bit indicates whether this broadcast message contains BTS Sectored Cell information or not.
– ‘0’ No Sector Information included.
– ‘1’ Sector Information included.
RTD Range
This bit indicates whether the RTD value covers only one time slot period or 8 time slot period. This bit will affect the RTD field so that there will be need for 3 bits more for RTD if whole 8 time slot period need to be indicated with RTD value.
– ‘0’ RTD value covers 1 time slot period.
– ‘1’ RTD value covers 8 time slots period.
RTD Accuracy
This contains two bits, which define what will be the accuracy of RTD value in this broadcast message. The accuracy will be coded as follows.
Table 5: Accuracy Range
|
1 |
0 |
Definition |
|
0 |
0 |
1/16 bit accuracy |
|
0 |
1 |
1/32 bit accuracy |
|
1 |
0 |
1/64 bit accuracy |
|
1 |
1 |
1/128 bit accuracy |
The RTD accuracy will affect the amount of bits needed to indicate the RTD value. The following table describes the accuracy related to needed bits.
Table 6: Amount of RTD bits needed
|
Time Slots |
Accuracy |
Amount of Bits Needed |
|
1 |
1/16 |
12 bits |
|
1/32 |
13 bits |
|
|
1/64 |
14 bits |
|
|
1/128 |
15 bits |
|
|
8 |
1/16 |
15 bits |
|
1/32 |
16 bits |
|
|
1/64 |
17 bits |
|
|
1/128 |
18 bits |
RTD Drift Factors Present
This bit indicates whether the RTD Drift Factors are present in this broadcast message. If RTDs Present bit indicates that the RTD Values are not included into this broadcast message, the state of this bit should be ignored and the RTD Drift Factors are not present in this broadcast message.
– ‘0’ RTD Drift Factors are not present in the message.
– ‘1’ RTD Drift Factors are present in the message.
RTDs Present
This bit indicates whether RTD Values IE is present in this broadcast or not.
– ‘0’ RTD Values IE not present.
– ‘1’ RTD Values IE present.
Number of Neighbours
These 5 bits are indicating the amount of neighbours are in System Information Neighbour List according to which this broadcast message was created. The number of neigbours indicated here makes sure that MS can decode back this broadcast message IEs as they were originally sended. If the MS has received different amount of neighbours in System Information Neighbour List than indicated in this field in broadcast message, the MS should ignore this broadcast message.
Range: 1 – 32 Neighbours.
4.1.1.2 Reference Time IE
The Reference Time IE gives information about the time when the RTD values in the broadcast message are calculated. The Reference Time IE contains the serving cell frame number modulo 131072 with 7 LSB bits omitted. The resolution of this Reference Time IE is thus 0.59 s. The Reference Time IE has 10 minutes periodicy. This IE is mandatory.
Range: 0 – 1023.
4.1.1.3 Ciphering Serial Number IE
The Ciphering Serial Number IE contains the serial number used in ciphering process of the broadcast message. The IE contains two octets, MSB part and LSB part. The serial number range is 0 – 65535. This IE is conditional and it is present only if the ciphering flag is active in Message Structure Definition IE.
Table 7: Ciphering Serial Number IE
|
MSB |
LSB |
|
Ciphering Serial Number (8 bits) |
Ciphering Serial Number (8 bits) |
4.1.1.4 Time Slot Scheme IE
This information element contains information about the serving cell channel and neighbour channel time slot scheme. The list starts with Serving Cell Channel and the rest of the list is in the same order as the neighbours in the System Information Neighbour List. For each list member there is one bit reserved to indicate whether the channel has 156.25 bits time slot duration or 156/157 bits time slot duration. This field is varying length depending on amount of neighbours of System Information Neighbour List (max 32) and maximum length of this IE is 33 bits (1+32 bits). The Serving Cell Channel time slot scheme is always indicated as the first (MSB) element of this field. This IE is mandatory.
– ‘0’ 156.25 bits time slot duration.
– ‘1’ 156/157 bits time slot duration.
Table 8: Time Slot Scheme
|
Serving Cell Ch (MSB) |
Neigh Chlast |
… |
Neigh Ch3 |
Neigh Ch2 |
Neigh Ch1 (LSB) |
|
0/1 |
0/1 |
… |
0/1 |
0/1 |
0/1 |
4.1.1.5 Neighbour Bitmap Definition IE
This IE defines which neighbours from System Information Neighbour List are included in this message. The IE is conditional and included only if Message Structure Definition IE’s Neighbour List Map indicates the use of this Neighbour Bitmap Definition. The list is in the same order as the neighbours in the System Information Neighbour List, the last member of the list presented as the MSB element of this field. For each Neighbour List channel number there is one bit reserved to indicate whether the neighbour is included into this broadcast message. This field is varying length depending on the amount of neighbours of System Information Neighbour List (max 32) and maximum length of this IE is 32 bits.
– ‘0’ Neighbour not included into this broadcast message.
– ‘1’ Neighbour included into this broadcast message.
Table 9: Neighbour Bitmap Definition
|
Neigh Chlast (MSB) |
… |
Neigh Ch3 |
Neigh Ch2 |
Neigh Ch1 (LSB) |
|
0/1 |
… |
0/1 |
0/1 |
4.1.1.6 Sectored Channels Definition IE
This information element defines which neighbours in System Information Neighbour List that are included in this broadcast message are belonging to sectored BTSs. This IE is conditional and included only if Message Structure Definition IE’s Sector Indicator is active. This field is varying length depending on amount of neighbours included into this broadcast message (max 32) and the maximum length of this IE is 33 bits (1+32 bits). The Serving Cell Channel sector indication is always indicated in MSB of this field and the neighbours are in same order as the neighbours in the System Information Neighbour List.
– ‘0’ Channel not included to sectored BTS.
– ‘1’ Channel included to sectored BTS.
Table 10: Sectored Channels Definition
|
Serving Ch (MSB) |
Neigh Chlast |
… |
Neigh Ch3 |
Neigh Ch2 |
Neigh Ch1 (LSB) |
|
0/1 |
0/1 |
… |
0/1 |
0/1 |
0/1 |
4.1.1.7 Sectored Channels BTS ID Definition IE
This information element defines what sectored channels are at the same BTS. The indication is done with three bits for each neighbour channel that is indicated to belong to sectored BTS (definition in Sectored Channels Definition IE). Belonging to the same BTS site is indicated with the same three bit binary ID, maximum 8 sectored BTS groups can be identified. This field is varying length depending on amount of sectored BTS in this broadcast message (max 33*3 bits = 99 bits when all 32 neighbours and the serving cell channel are belonging to some sector). This field follows the order of channels that have indicated to be belonging to sectored BTS in Sectored Channels Definition starting from the MSB. This IE is conditional and included only if Message Structure Definition IE’s Sector Ind is active.
Table 11: Sectored Channels BTS ID Definition
|
2 |
1 |
0 |
Definition |
|
0 |
0 |
0 |
Sectored BTS ID1 |
|
0 |
0 |
1 |
Sectored BTS ID2 |
|
0 |
1 |
0 |
Sectored BTS ID3 |
|
0 |
1 |
1 |
Sectored BTS ID4 |
|
1 |
0 |
0 |
Sectored BTS ID5 |
|
1 |
0 |
1 |
Sectored BTS ID6 |
|
1 |
1 |
0 |
Sectored BTS ID7 |
|
1 |
1 |
1 |
Sectored BTS ID8 |
Table 12: Sectored Channels BTS ID Definition
|
Indicated Sectored Serving Channel (MSB) |
Indicated Sectored Neighbourlast |
… |
Indicated Sectored Neighbour3 |
Indicated Sectored Neighbour2 |
Indicated Sectored Neighbour1 (LSB) |
|
Sec. BTS ID X (3 bits) |
Sec. BTS ID X (3 bits) |
… |
Sec. BTS ID X (3 bits) |
Sec. BTS ID X (3 bits) |
Sec. BTS ID X (3 bits) |
4.1.1.8 Sectored BTS Sync/Async Definition IE
This information element defines whether the indicated sectored BTS site contains synchronized or asynchronized channels. The sync/async is informed with one bit per sectored BTS ID. This field follows the order of IDs in Sectored Channels BTS ID Definition. This field is varying length depending on amount of sectored BTS ID in this broadcast message (max 8 bits). This IE is conditional and is included only if Message Structure Definition IE’s Sector Ind is active.
– ‘0’ Sectored BTS contains async channels.
– ‘1’ Sectored BTS contains sync channels.
Table 13: Sectored BTS Sync/Async Definition
|
Sec BTSLast (MSB) |
… |
Sec BTSID3 |
Sec BTSID2 |
Sec BTSID1 (LSB) |
|
0/1 |
… |
0/1 |
0/1 |
0/1 |
4.1.1.9 Multiframe Offset Values IE
This information element defines the neighbour channel’s 51 Multiframe Values. The 51 Multiframe Offset Values are describing the offset value related to the Serving Cell 51 Multiframe Value. This field is needed when co-channels must be identified from the real neighbour channels (included into System Information Neighbour List). Each 51 Multiframe Offset Value is 6 bits long denoting the offset value to the Serving Cell 51 Multiframe number. The 51 Multiframe Offset Values must be declared to all neighbours in this broadcast message and the values are in the same order as the neighbours in the System Information Neighbour List. The maximum length of this IE is 192 bits (32*6 bits). This IE is mandatory.
Range: 0 – 50 Frames
Table 14: 51 Multiframe Offset Values IE
|
51 MF OffsetNbLast (MSB) |
… |
51 MF Offset Nb3 |
51 MF Offset Nb2 |
51 MF Offset Nb1 (LSB) |
|
Offset Value (6 bits) |
… |
Offset Value (6 bits) |
Offset Value (6 bits) |
Offset Value (6 bits) |
4.1.1.10 BCC Definition IE
This information element defines the BBC (Base Station Color Code) values. The BCC is needed to know what training sequence is in use in the bursts in BCCH frequency. Each BCC is 3 bits long denoting the one of the 8 possible TSCs (Training Sequence Codes) possible to be used in bursts. BCC values must be declared to all neighbours in this message and the values are in the same order as the neighbours in the System Information Neighbour List. The maximum length of this IE is 96 bits (32*3 bits). This IE is mandatory.
Table 15: BCC Definition IE
|
BCCNbLast (MSB) |
… |
BCCNb3 |
BCC Nb2 |
BCC Nb1 (LSB) |
|
BCC Value (3 bits) |
… |
BCC Value (3 bits) |
BCC Value (3 bits) |
BCC Value (3 bits) |
4.1.1.11 RTD Drift Factor Values IE
This IE contains the drift factor values for the Channel RTD Values included into this broadcast message. The RTD Drift Factor Values indicate the RTD drift in meters per second. Positive and negative RTD Drift Factors can be indicated as well as no drift value. This information element is conditional and included if the RTD Drift Factors Present bit in the Message Structure Definition IE is active and the RTDs Present bit is active. The RTD Drift Factors are included into the broadcast message with same conditions and in same order than the Channel RTD Values which are described in Channel RTD Values IE section (subclause 4.1.1.12). This IE should be ciphered if the ciphering is active. Each RTD Drift Factor Value is 5 bits long and the coding is as follows:
Table 16: RTD Drift Factor Values
|
Positive/Negative MSB |
Coding Bits MSB LSB |
Definition |
|||
|
3 |
3 |
2 |
1 |
0 |
|
|
Don’t care |
0 |
0 |
0 |
0 |
0 m/s |
|
0 |
0 |
0 |
0 |
1 |
+0.33 m/s |
|
0 |
0 |
0 |
1 |
0 |
+0.66 m/s |
|
0 |
0 |
0 |
1 |
1 |
+1 m/s |
|
0 |
0 |
1 |
0 |
0 |
+1.33 m/s |
|
0 |
0 |
1 |
0 |
1 |
+1.66 m/s |
|
0 |
0 |
1 |
1 |
0 |
+2 m/s |
|
0 |
0 |
1 |
1 |
1 |
+2.5 m/s |
|
0 |
1 |
0 |
0 |
0 |
+3 m/s |
|
0 |
1 |
0 |
0 |
1 |
+4 m/s |
|
0 |
1 |
0 |
1 |
0 |
+5 m/s |
|
0 |
1 |
0 |
1 |
1 |
+7 m/s |
|
0 |
1 |
1 |
0 |
0 |
+9 m/s |
|
0 |
1 |
1 |
0 |
1 |
+11 m/s |
|
0 |
1 |
1 |
1 |
0 |
+13 m/s |
|
0 |
1 |
1 |
1 |
1 |
+15 m/s |
|
1 |
0 |
0 |
0 |
1 |
-0.33 m/s |
|
1 |
0 |
0 |
1 |
0 |
-0.66 m/s |
|
1 |
0 |
0 |
1 |
1 |
-1 m/s |
|
1 |
0 |
1 |
0 |
0 |
-1.33 m/s |
|
1 |
0 |
1 |
0 |
1 |
-1.66 m/s |
|
1 |
0 |
1 |
1 |
0 |
-2 m/s |
|
1 |
0 |
1 |
1 |
1 |
-2.5 m/s |
|
1 |
1 |
0 |
0 |
0 |
-3 m/s |
|
1 |
1 |
0 |
0 |
1 |
-4 m/s |
|
1 |
1 |
0 |
1 |
0 |
-5 m/s |
|
1 |
1 |
0 |
1 |
1 |
-7 m/s |
|
1 |
1 |
1 |
0 |
0 |
-9 m/s |
|
1 |
1 |
1 |
0 |
1 |
-11 m/s |
|
1 |
1 |
1 |
1 |
0 |
-13 m/s |
|
1 |
1 |
1 |
1 |
1 |
-15 m/s |
Table 17: RTD Drift Factor Values IE
|
RTD Drift Factor NbLast (MSB) |
… |
RTD Drift Factor Nb3 |
RTD Drift Factor Nb2 |
RTD Drift Factor Nb1 (LSB) |
|
RTD Drift Factor Value |
… |
RTD Drift Factor Value |
RTD Drift Factor Value |
RTD Drift Factor Value |
4.1.1.12 Channel RTD Values IE
This IE contains the channel RTD values relative to the serving BTS. The RTD is defined as TBTS – TServ, where TBTS is the time of the start of TS0 (Time Slot 0) in the neighbor BTS, and Tserv is the time of the start of the TS0 in the serving BTS. The RTD value covers 1 or 8 time slot period with 1/16-1/128 bit accuracy. The 1 or 8 time slot period as well as 1/16-1/128 bit accuracy is defined in Message Structure Definition IE. The RTD values included here are conditional to the RTDs Present and Neighbour List Map (Message Structure Definition IE), Neighbour Bitmap Definition IE, Sectored Channels Definition IE, Sectored Channels BTS ID Definition and Sectored BTS Sync/Async Definition. This IE should be ciphered if the ciphering is active. The decision which BTS RTD value is included in this broadcast message has the following decision process:
– Channel RTD Values IE should not be included at all if RTDs Present bit (Message Structure Definition IE) is not active.
– Neighbours in this broadcast message are defined in Neighbour List Map (Message Structure Definition IE) and in case the Neighbour Bitmap Definition is active then the Neighbour Bitmap Definition IE declares the Neighbours included into this broadcast message.
– If Sector Indicator in Message Structure Definition IE is not active the RTD values are included for all neighbours in this broadcast message.
– If sector indicator in Message Structure Definition IE is active then the Neighbour channels that are not belonging to sectored BTS the RTD values are included directly according to neighbour list order.
– If sector indicator in Message Structure Definition IE is active then the Neighbour channels that are belonging to sectored BTS, the Sectored BTS ID values group the neighbour channels into the groups. If the Sectored BTS ID group is indicated to be synchronous then only one RTD value (decided by SMLC) per the Sectored BTS ID group is included into this broadcast message, if the Sectored BTS ID group is indicated to be asyncronous then all the neighbour channel RTDs belonging to the Sectored BTS ID group have to be included into this broadcast message.
Table 18: Channel RTD Value IE
|
(MSB) Varying Length (12-18 bits) (LSB) |
|
Neighbour RTD (Last) (MSB) |
|
Neighbour RTD (Last-1) |
|
… |
|
Neighbour RTD (2) |
|
Neighbour RTD (1) (LSB) |
The fields that are included into the Channel RTD Value IE may contain RTD values of neighbour channels and the RTD values of the sectored channels BTS ID. The RTD values should be included into this IE in following order:
– Starting from the last channel in the System Information Neighbour List that is included into this broadcast message.
– First are reported the neighbour channels that are not belonging to the Sectored Channels BTS ID groups and then the Sectored Channels ID groups from 1 up to 8 depending the amount of groups. See annex B for example.
If the RTD value is invalid, following values in the RTD field are reserved for this indication (e.g. if invalid RTD value is indicated the MS shall discard the previous values).
Table 19: Invalid RTD Value Codes
|
Time Slots |
Accuracy |
Amount of Bits in RTD |
Invalid RTD Code in Hex |
|
1 |
1/16 |
12 bits |
FFF |
|
1/32 |
13 bits |
1FFF |
|
|
1/64 |
14 bits |
3FFF |
|
|
1/128 |
15 bits |
7FFF |
|
|
8 |
1/16 |
15 bits |
7FFF |
|
1/32 |
16 bits |
FFFF |
|
|
1/64 |
17 bits |
1FFFF |
|
|
1/128 |
18 bits |
3FFFF |
This field is varying length depending on amount of Neighbour Channels included as well as amount of sectored cells and the nature (sync/async) of sectored cells. One RTD value has varying length of 12 bits to 18 bits indicating the amount on 1/16-1/128 bit durations over 1 time slot or 8 time slots. Maximum length of this IE is 576 bits (32*18 bits).
4.1.1.13 Serving Cell Location IE
This IE contains the Serving Cell Latitude/Longitude information. This IE should be ciphered if the ciphering is active. This IE is mandatory.
Serving Cell Latitude
This field indicates WGS-84 latitude with fixed length of 24 bits. Latitude value is coded according to 3GPP TS 23.032. This field is mandatory.
Table 20: Serving Cell Latitude
|
(MSB) 24 – 1 (LSB) |
|
Serving Cell Latitude (24 bits) |
Serving Cell Longitude
This field indicates WGS-84 longitude with fixed length of 24 bits. Latitude value is coded according to 3GPP TS 23.032. This field is mandatory.
Table 21: Serving Cell Longitude
|
(MSB) 24 – 1 (LSB) |
|
Serving Cell Longitude (24 bits) |
4.1.1.14 Relative Neighbour Location IE
This information element defines the location of Neighbour Channels (BTS) relative to Serving Cell Location. This IE should be ciphered if the ciphering is active. The fields are varying length depending on amount of neighbour channels and sectored cells included in this broadcast message. The location information per neighbour has two elements, Relative North and Relative East. The Relative North positive values indicate north direction, negative values indicate south direction from Serving Cell Location. The Relative East positive values indicate east direction and negative values indicate west direction from Serving Cell Location. The MSB bit in Relative North/East value is reserved for sign indication (positive = 0, negative = 1). The values are expressed in meters according to the accuracy resolution which is defined by Accuracy Range bits in Message Structure Definition IE. For example if the Accuracy Range is set to 20 km and there is 15 bits (1+14 bits) reserved for Relative North/East values this means 0.6 m accuracy for Relative North or East value. This IE is mandatory.
The amount of Relative North/East pairs depends on neighbours included in this broadcast message as well as the amount sectored cells since only one Relative North/East pair is included per Sectored BTS ID.
Table 22: Relative Neighbour Location
|
(MSB) Varying Length (LSB) |
|
Relative North Value Neighbour (Last) (MSB) |
|
Relative East Value Neighbour (Last) |
|
Relative North Value Neighbour (Last-1) |
|
Relative East Value Neighbour (Last-1) |
|
… |
|
Relative North Value (2) |
|
Relative East Value (2) |
|
Relative North Value (1) |
|
Relative East Value (1) (LSB) |
The decision what Relative North/East Values are included in this broadcast message has following decision process:
– Neighbours in this broadcast message is defined in Neighbour List Map (Message Structure Definition IE) and in case the Neighbour Bitmap Definition is active then the Neighbour Bitmap Definition IE declares the Neighbours included into this broadcast message.
– If Sector Indicator in Message Structure Definition IE is not active the Relative North/East Values are included in the same order as they are indicated in Message Structure Definition IE / Neighbour Bitmap Definition IE.
– If sector indicator in Message Structure Definition IE is active then the Neighbour channels that are not belonging to sectored BTS Relative North/East Values are included directly according to neighbour list order.
– If sector indicator in Message Structure Definition IE is active then the Neighbour channels that are belonging to sectored BTS, the Sectored BTS ID values group the neighbour channels into the groups. The Relative North/East Values are included in the broadcast message so that only one Relative North/East Value per Sectored BTS ID is included.
The fields that are included into the Relative Neighbour Location IE may contain the Relative North/East values of neighbour channels and the Relative North/East values of the sectored channels BTS ID groups. The RTD values should be included into this IE in following order:
– Starting from the last channel in the System Information Neighbour List that is included into this broadcast message.
– First are reported the neighbour channels that are not belonging to the Sectored Channels BTS ID groups and then the Sectored Channels ID groups from 1 up to 8 depending the amount of groups.
– The neighbour channel/BTS ID value will always contain Relative North value first and then Relative East value. The values are expressed in meters according to the Accuracy Range in the Message Structure Definition IE. See annex B for example.
The bits available for Relative North/East Values can be calculated with following formula:
z = number of neighbours in System Info Neighbour List
x = number of neighbours in this broadcast message
a = number of channels in sectors
b = number of BTS IDs
c = RTD accuracy (12-18 bits)
w = Neighbour Bitmap used (yes = 1, no = 0)
s = RTDs Present (yes = 1, no = 0)
d = RTD Drift Factors included (yes = 1, no = 0)
y = bits per Relative Latitude / Longitude value
Int(y) = (561-11*x–3*a–b-s*(c+d*5)*(x-a+b)-w*z)/(2*(x-a+b))
If the y doesn’t go even, the bits that remain are used as one extra bit (extension bit) per one Relative North or East value in same order as the values are presented in this IE as long as there are remain bits available. See Annex B for example.
4.2 GPS Assistance Data Broadcast Message
The GPS Assistance Data message contents are defined in this clause. The GPS Assistance Data message is built so that it is fitted into a fixed length message not necessary occupying the whole message. In case that the fixed length message has less information elements than bits available then the rest of message is filled with fill bits. The information elements are in the order which is described in subclause 4.2.1 and no undefined spare bits are allowed between elements. The channel to broadcast the GPS Assistance Data message is CBCH over which the SMSCB DRX service is used. One SMSCB message has fixed information data length of 82 octets and the maximum length of GPS Assistance Data is 82 octets. MS can identify the LCS SMSCB message with Message Identifiers declared in 3GPP TS 23.041. Example of GPS Assistance Data Broadcast Message is in Annex C. In addition, an Integrity Monitor (IM) shall detect unhealthy (e.g. failed/failing) satellites. When an unhealthy (i.e. failed/failing) satellite is detected, the assistance data, including DGPS corrections, shall not be supplied for that particular satellite. If more satellites are unhealthy, the same can be done to exclude them from the final location calculation. Even when all satellites are healthy, the IM shall monitor the quality of the DGPS corrections. It shall make use of the pseudoranges derived by the DGPS reference receiver, correct them using the DGPS reference receiver-generated DGPS corrections, and compute a position from the corrected pseudo ranges. This computed position shall then be compared with the known, surveyed location of the DGPS reference receiver to compute a DGPS positioning error. Positioning errors which are excessive relative to DGPS expected accuracy levels shall be used to inform users of measurement quality via the UDRE parameter.
4.2.1 GPS Assistance Data Content
The GPS Assistance Data Message contents are defined in this clause. It contains three data sets: DGPS correction, ephemeris and clock correction, almanac and other data information. The empheris, clock correction, almanac and other data are obtained from GPS navigation message. It is built so that it fits into a fixed length message not necessarily occupying the whole message. In case that the fixed length message has less information elements than bits available then the rest of message is filled with fill bits.
This message is built to allow for broadcast rates that more closely match the time of applicability of the contained data.
EXAMPLE: With a 30 s rate for DGPS broadcast, mobile staion (MS) can effectively remove degration caused by SA.
GPS subframes 1 through 3 (ephemeris and clock correction data) are contained in the same single broadcast message. With a 90 s rate, Mobile Stations (MS) can receive all visible ephemeris and clock correction data at twelve to eighteen minute intervals depending on number of visible satellites. Subframes 4 and 5 (almanac, ionospheric delay, and other more slowly changing data can be sent at another rate, such as once every several hours. By splitting the data into separate data sets (all based on the same single format), the data can be sent at rates that are correspond to its validity time and/or the desire to update the mobile stations within its network at a particular rate. The Information Elements (IEs) in the message are listed in table 23.
Table 23: Information Elements of GPS Assistance Data message
|
Parameter |
Bits |
Resolution |
Range |
Units |
Occurrences |
Presence |
Ref |
|
|
Cipher Control |
Cipher On/Off |
1 |
— |
0 – 1 |
— |
1 |
M |
|
|
Ciphering Key Flag |
1 |
— |
0 – 1 |
— |
1 |
M |
||
|
Ciphering Serial Number |
16 |
— |
0 – 65535 |
— |
1 |
C |
||
|
Data |
638 |
— |
– |
— |
— |
M |
||
Cipher Control IE
This information element contains two bits indicating the ciphering properties of the received message. This IE is mandatory.
Cipher On/Off
This IE indicates whether this broadcast message has been ciphered or not. A value of "0" indicates that ciphering is off, while a value of "1" indicates that ciphering is active. The Data IE is ciphered if ciphering is active.
Ciphering Key Flag
The MS always receives two (2) cipher keys during the location update procedure. One of the keys is time-stamped to be current one and the other is time-stamped to be the next one. Thus, the MS always has two cipher keys in memory. The Cipher Key Change Indicator in this broadcast message instructs the MS whether to use current or next cipher key for deciphering the received broadcast message. The MS shall interpret this IE as follows:
– Ciphering Key Flag(previous message) = Ciphering Key Flag(this message) => Deciphering Key not changed.
– Ciphering Key Flag(previous message) <> Ciphering Key Flag(this message) => Deciphering Key changed.
Ciphering Serial Number IE
The Ciphering Serial Number IE contains the serial number used in ciphering process of the broadcast message. The IE contains two octets, MSB part and LSB part. The serial number range is 0 – 65535. This IE is conditional and it is present only if the ciphering flag is active in Cipher Control IE.
Table 24: Ciphering Serial Number IE
|
MSB |
LSB |
|
Ciphering Serial Number (8 bits) |
Ciphering Serial Number (8 bits) |
Data IE
The Data IE contains the GPS assistance data included in the broadcast message. The Data IE may contain DGPS Correction Data (subclause 4.2.1.1), Emphemeris and Clock Correction Data (subclause 4.2.1.2) or Almanac and Other Data (subclause 4.2.1.3). The Data IE content is indicated with the SMSCB message identifier specified in 3GPP TS 23.041 and 3GPP TS 23.041. When ciphering is active (indicated with Ciphering Control Flags), the ciphering will apply only to the Data IE element. This IE is mandatory.
4.2.1.1 DGPS Correction Data
This subclause describes the contents of the broadcast message for differential corrections. The message contents are based on a Type-1 message of version 2.2 of the RTCM-SC-104 recommendation for differential service RTCM-SC104. This format is a standard of the navigation industry and is supported by all DGPS receivers. For a 11 satellites, the length of the broadcast message is 82 octets, which also is the maximum length of an SMSCB message. The information elements (IEs) in the message are listed in table 26. If any of the conditional elements (Ciphering Serial Number, BTS Clock Drift, FN, TN and BN) are not included to the message, spare bits will be transmitted instead of these fields. The spare bits have equal length to the conditional IE, so that the message structure is unchanged (see annex C). The spare bits are set to ‘0’.
Table 26: DGPS Correction Data
|
Parameter |
Bits |
Resolution |
Range |
Units |
Occurrences |
Precence |
Ref |
|
|
GSM Time Present |
1 |
— |
0 – 1 |
— |
1 |
M |
4.2.1.2 |
|
|
BTS Clock Drift Present |
1 |
— |
0 – 1 |
— |
1 |
M |
4.2.1.3 |
|
|
BTS Clock Drift |
4 |
12.5 x 10-3 |
0.1 |
sec/sec |
1 |
C |
4.2.1.4 |
|
|
Reference Location |
48 |
— |
— |
Degrees |
1 |
M |
4.2.1.5 |
|
|
Reference time |
FN |
22 |
— |
0 – 524287 |
frames |
1 |
C |
4.2.1.6 |
|
TN |
3 |
— |
0 – 7 |
timeslots |
1 |
C |
||
|
BN |
8 |
— |
0 – 156 |
bits |
1 |
C |
||
|
GPS TOW |
20 |
1 |
0 – 604794 |
sec |
1 |
M |
||
|
Status/Health |
3 |
— |
0 – 7 |
— |
1 |
M |
4.2.1.7 |
|
|
N_SAT |
4 |
— |
1 – 12 |
— |
1 |
C |
4.2.1.8 |
|
|
DGPS Corrections |
Satellite ID |
6 |
— |
1 – 64 |
— |
N_SAT |
C |
4.2.1.9 |
|
IODE |
8 |
— |
0 – 239 |
— |
||||
|
UDRE |
2 |
— |
0 – 3 |
— |
||||
|
PRC |
12 |
0.32 |
655.34 |
m |
||||
|
RRC |
8 |
0.032 |
4.064 |
m/s |
||||
|
Delta PRC2 |
8 |
1 |
127 |
M |
||||
|
Delta RRC2 |
4 |
0.032 |
0.224 |
m/s |
||||
4.2.1.1.1 GSM Time Present IE
This field indicates whether or not GSM air-interface timing information values for the serving cell are present in this message. The MS shall interpret a value of "1" to mean that GSM timing informationvalues (FN,TN and BN) are present, and "0" to mean that only the GPS TOW field value is provided. This field is mandatory.
4.2.1.1.2 BTS Clock Drift Present IE
This IE is indication whether this broadcast message contains BTS Clock Drift IE value or not. The length of this IE is one bit. The value ‘1’ indicates that BTS Clock Drift IE value is present, ‘0’ indicates that the IE valueis not present in this proadcast message. This IE is mandatory.
4.2.1.1.3 BTS Clock Drift IE
This IE provides an estimate of the drift rate of the BTS clock relative to GPS time. It has units of sec/sec (ppm) and a range of 0.1. This IE aids the MS in maintaining the relation between GPS and cell timing over a period of time. The value of the clock drift is valid starting at the time contained in the Reference Time IE. A positive value for BTS Clock Drift indicates that the BTS clock is running at a greater frequency than desired. This IE is conditional and value is included in the message if BTS Clock Drift Present IE flag is ‘1’.
4.2.1.1.4 Reference Location IE
The Reference Location field contains a 2-D location (without uncertainty) specified as per 3GPP TS 23.032. The purpose of this field is to provide the MS with a priori knowledge of its location in order to improve GPS receiver performance.
4.2.1.1.5 Reference Time IE
This IE specifies the relationship between GPS time and air-interface timing of the BTS transmission in the serving cell. The GPS TOW (time-of-week) has a one-second resolution with a range of 0 to 604799. The FN, TN, and BN IEs are respectively the GSM frame number, timeslot number, and bit number of the BTS transmissions for the serving cell that occur at that GPS time. The frame number FN is modulo-219 (0 – 524287) and the MS shall resolve the ambiguity by interpreting the frame to be as near as possible to the current frame of the serving BTS. The GPS TOW IE is mandatory. The FN, TN, and BN IEs are conditional and the values are present only when GSM Time Present bit is ‘1’.
4.2.1.1.6 Status/Health IE
This IE indicates the status of the differential corrections contained in the broadcast message. It is equivalent to the "Station Health" IE in the common header for all reference station messages specified in RTCM-SC104. The values of this IE and their respective meanings are shown below in table 25. This IE is mandatory.
Table 25: Values of Correction Status
|
Code |
Indication |
|
000 |
UDRE Scale Factor = 1.0 |
|
001 |
UDRE Scale Factor = 0.75 |
|
010 |
UDRE Scale Factor = 0.5 |
|
011 |
UDRE Scale Factor = 0.3 |
|
100 |
UDRE Scale Factor = 0.2 |
|
101 |
UDRE Scale Factor = 0.1 |
|
110 |
No data available |
|
111 |
Data is invalid – disregard |
The first six values in this IE indicate valid differential corrections in the broadcast message. When using the corrections values described below, the "UDRE Scale Factor" value is applied to the UDRE values contained in the message. The purpose is to indicate an estimate in the amount of error in the corrections.
The value "110" indicates that the source of the differential corrections (e.g. reference station or external DGPS network) is currently not providing information. The value "111" indicates that the corrections provided by the source are invalid, as judged by the source. In either case, the broadcast message shall contain no differential corrections. All MS that read the broadcast message shall contain the appropriate logic to ignore any data IEs following a Correction Status IE having a value of "110" or "111".
4.2.1.1.7 N_SAT IE
This IE indicates the number of satellites (N_SAT) for which differential corrections are available. The maximum number of satellites that can be included into the message is 12. This IE is conditional and included if Correction Status IE value is not 110 or 111.
4.2.1.1.8 DGPS Corrections IE
This IE contains GPS differential correction data. Each element described below will appear N_SAT times in this message, once for each satellite for which corrections are available. This IE is conditional and included if Correction Status IE value is not 110 or 111.
Satellite ID
This IE identifies the satellite for which the corrections are applicable. This value is the same as the PRN number provided in the navigation message transmitted by the particular satellite.The range is 0 to 31, with 0 indicating satellite number 32 as perRTCM-SC104.
IODE
This IE is the sequence number for the ephemeris for the particular satellite. The MS can use this IE to determine if new ephemeris is used for calculating the corrections that are provided in the broadcast message. This eight-bit IE is incremented for each new set of ephemeris for the satellite and may occupy the numerical range of [0, 239] during normal operations. For more information about this field can be found from RTCM-SC104.
User Differential Range Error (UDRE)
This IE provides an estimate of the uncertainty (1-) in the corrections for the particular satellite. The value in this IE shall be multiplied by the UDRE Scale Factor in the common Corrections Status IE to determine the final UDRE estimate for the particular satellite. The meanings of the UDRE values are described in table 27.
Table 27: Values of UDRE
|
Value |
Indication |
|
00 |
UDRE 1.0 m |
|
01 |
1.0 m < UDRE 4.0 m |
|
10 |
4.0 m < UDRE 8.0 m |
|
11 |
8.0 m < UDRE |
Each UDRE value shall be adjusted based on the operation of an Integrity Monitor (IM) function which exists at the network (SMLC, GPS server, or reference GPS receiver itself). Positioning errors derived at the IM which are excessive relative to DGPS expected accuracy levels shall be used to scale the UDRE values to produce consistency.
Pseudo-Range Correction (PRC)
This IE indicates the correction to the pseudorange for the particular satellite at the reference time, t0. As mentioned above, this reference time is the GPS TOW. The value of this IE is given in meters (m) and the resolution is 1. The method of calculating this IE are described in RTCM-SC104.
Pseudo-Range Rate Correction (RRC)
This IE indicates the rate-of-change of the pseudorange correction for the particular satellite, using the satellite ephemeris identified by the IODE IE. The value of this IE is given in meters per second (m/sec) and the resolution is 0.032. For some time t1 > t0, the corrections are estimated by:
PRC(t1, IODE) = PRC(t0, IODE) + RRC(t0, IODE)(t1 – t0),
and the MS uses this to correct the pseudorange it measures at t1, PRm(t1), by:
PR(t1, IODE) = PRm(t1, IODE) + PRC(t1, IODE).
Delta Pseudo-Range Correction 2 (Delta PRC2)
This IE indicates the difference in the pseudorange correction between the satellite’s ephemeris identified by IODE and the previous ephemeris two issues ago IODE –2. The value of this IE is given in meters (m) and the resolution is 0.32. The method of calculating this IE are described in RTCM-SC104.
Delta Pseudo-Range Rate Correction 2 (Delta RRC2)
This IE indicates the difference in the pseudorange rate-of-change correction between the satellite’s ephemeris identified by IODE and IODE-2. The value of this IE is given in meters per second (m/sec) and the resolution is 0.032. For some time t1 > t0, the corrections for IODE–2are estimated by:
PRC(t1, IODE–2) = [PRC(t0, IODE) + DeltaPRC(t0, IODE)] + [RRC(t0, IODE) + DeltaRRC(t0, IODE)](t1-t0);
and the MS uses this to correct the pseudorange it measures at t1 using ephemeris IODE-2, PRm(t1, IODE-2), by:
PR(t1, IODE–2) = PRm(t1, IODE–2) + PRC(t1, IODE–2).
If there is not an ephemeris set for a currently visible satellite that is two issues old, then the parameters Delta PRC2 and Delta RRC2 are both set to zero.
4.2.1.2 Ephemeris and Clock Correction Data
This subclause describes the contents of the Data for ephemeris and clock corrections of a particular satellite. These IE fields are extracted from the subframes 1 to 3 of the GPS navigation message. They are listed in table 28.
Table 28: Ephemeris and Clock Correction Data (per-satellite fields – (1) = Positive range only)
|
Parameter |
Bits |
Resolution |
Range |
Units |
Occurrences |
Presence |
|---|---|---|---|---|---|---|
|
Transmission TOW |
20 |
1 |
0 – 604799 |
seconds |
1 |
M |
|
SVID/PRNID |
6(1) |
— |
0 – 63 |
— |
1 |
M |
|
TLM Message |
14 |
— |
0 – 16383 |
— |
1 |
M |
|
TLM Reserved (C) |
2 |
— |
0 – 3 |
— |
1 |
M |
|
HOW |
22 |
— |
0 – 4194303 |
— |
1 |
M |
|
WN |
10 |
— |
0 – 1023 |
weeks |
1 |
M |
|
C/A or P on L2 |
2 |
— |
0 – 3 |
Boolean |
1 |
M |
|
URA Index |
4 |
— |
0 – 15 |
Boolean |
1 |
M |
|
SV Health |
6 |
— |
0 – 63 |
Boolean |
1 |
M |
|
IODC |
10(1) |
— |
0 – 1023 |
— |
1 |
M |
|
L2 P Data Flag |
1 |
— |
0 – 1 |
Boolean |
1 |
M |
|
SF1 Reserved |
87 |
— |
Ful l Range |
— |
1 |
M |
|
TGD |
8 |
2-31 |
-128 – 127 |
seconds |
1 |
M |
|
toc |
16(1) |
24 |
0 – 604784 |
seconds |
1 |
M |
|
Af2 |
8 |
2-55 |
-128 – 127 |
sec/sec2 |
1 |
M |
|
Af1 |
16 |
2-43 |
-32768 – 32767 |
sec/sec |
1 |
M |
|
Af0 |
22 |
2-31 |
-2097152 – 2097151 |
seconds |
1 |
M |
|
Crs |
16 |
2-5 |
-32768 – 32767 |
meters |
1 |
M |
|
n |
16 |
2-43 |
-32768 – 32767 |
semi-circles/sec |
1 |
M |
|
M0 |
32 |
2-31 |
-2147483648 – 2147483647 |
semi-circles |
1 |
M |
|
Cuc |
16 |
2-5 |
-32768 – 32767 |
meters |
1 |
M |
|
E |
32(1) |
2-33 |
0 – 4294967295 |
— |
1 |
M |
|
Cus |
16 |
2-29 |
-32768 – 32767 |
radius |
1 |
M |
|
(A)1/2 |
32(1) |
2-19 |
0 – 4294967295 |
meters1/2 |
1 |
M |
|
toe |
16(1) |
24 |
0 – 604784 |
seconds |
1 |
M |
|
Fit Interval Flag |
1 |
— |
0 – 1 |
Boolean |
1 |
M |
|
AODO |
5 |
900 |
0 – 31 |
seconds |
1 |
M |
|
Cic |
16 |
2-29 |
-32768 – 32767 |
radians |
1 |
M |
|
OMEGA0 |
32 |
2-31 |
-2147483648 – 2147483647 |
semi-circles |
1 |
M |
|
Cis |
16 |
2-29 |
-32768 – 32767 |
radians |
1 |
M |
|
i0 |
32 |
2-31 |
-2147483648 – 2147483647 |
semi-circles |
1 |
M |
|
Crc |
16 |
2-29 |
-32768 – 32767 |
meters |
1 |
M |
|
|
32 |
2-31 |
-2147483648 – 2147483647 |
semi-circles |
1 |
M |
|
OMEGAdot |
24 |
2-43 |
-8388608 – 8388607 |
Semi-circles/sec |
1 |
M |
|
Idot |
14 |
2-43 |
-8192 – 8191 |
Semi-circles/sec |
1 |
M |
|
Spares/zero fill |
20 |
— |
— |
— |
1 |
M |
Transmission TOW
This field indicates the approximate GPS time-of-week when the message is broadcast. The MS should interpret this field as a very coarse estimate of the current time.
SVID/PRNID
The satellite ID of the data from which this signal was obtained.
Rest of Fields
The rest of fields are defined as in figure 20-1 of ICD-GPS-200.
4.2.1.3 Almanac and Other Data
This subclause describes the contents of the Data for ionospheric delay, UTC offset, and Almanac. These IE fileds are extracted from the subframes 4 and 5 of the GPS navigation message, excluding the parity bits and other redundant bits. They are listed in table 29.
Table 29: Almanac and Other Data
|
Parameter |
Bits |
Resolution |
Range |
Occurrences |
Presence |
|
Transmission TOW |
20 |
1 |
0 – 604799 |
1 |
M |
|
SV Mask |
32 |
— |
— |
1 |
M |
|
LSB TOW |
8 |
1 |
0 – 255 |
1 |
M |
|
SFID 0 |
1 |
1 |
0 – 1 |
Repeat three times: Each corresponds to a different page no. as described in table 29 |
M |
|
Data ID |
2 |
— |
— |
||
|
Page No. |
6 |
1 |
1 – 25 |
||
|
Word 3 |
16 |
COSP |
COSP |
||
|
Word 4 |
24 |
COSP |
COSP |
||
|
Word 5 |
24 |
COSP |
COSP |
||
|
Word 6 |
24 |
COSP |
COSP |
||
|
Word 7 |
24 |
COSP |
COSP |
||
|
Word 8 |
24 |
COSP |
COSP |
||
|
Word 9 |
24 |
COSP |
COSP |
||
|
Word 10 |
22 |
COSP |
COSP |
||
|
Spares/zero fill |
5 |
— |
— |
1 |
M |
Transmission TOW
This field indicates the approximate GPS time-of-week when the message is broadcast. The MS should interpret this field as a very coarse estimate of the current time.
SV Mask
This field indicates the satellites that contain the pages being broadcast in this data set.
LSB TOW
This field indicates the least significant 8 bits of the TOW. See ICD-GPS-200, figure 20-2.
COSP
Format Conditional on Subframe ID and Page Number. See ICD-GPS-200, subclause 20.3.3.5, figure 20-1.
SFID 0
This one bit field conveys the least significant bit of the SubFrame(SF) ID for which the following word 3 through word 10 data applies. Zero indicates subframe ID = 4, and One indicates Subframe ID = 5.
Data ID
Indicates the Data ID field contained in the indicated subframe, word 3, most significant 2 bits, as defined by ICD-GPS-200.
Page No.
Six-bit field indicates the Page ID of the indicated subframe for which the following Word 3 through Word 10 data applies. The page field and SFID field define the data content and format for the following word 3 through word 10 data fields as defined by ICD-GPS-200.
Word 3 through Word 10
Information bits (16, 22 or 24) that are contained in the respective words of the indicated subframe and page, excluding 2 bit "t" from Word 10. See reference ICD-GPS-200 for more information.
Each broadcast Almanac and Other Data message contains three subframes of information. All three of subframe pages in this data set can be from the same subframe ID (all from subframe 5 for example), or a mixed set containing some subframe 4 and some subframe 5 data.
Table 29 shows the subframe and page numbers corresponding to the Almanac, SV Health, and Iono / UTC Correction data. A total of 35 subframes must be broadcast if all the information is to be provided to the MS. Given that three subframes worth of content can be delivered per broadcast message, it will take only 12 broadcast messages to deliver the entire data set shown in table 29. If the data listed in table 29 is broadcast at the rate of approximately once per four hours, one Almanac and Other Data message must be broadcast on average every 20 minutes. An alternate approach is to broadcast the 12 messages as a set closely together in time, but with four-hour duration between sets. Note that the four-hour figure is only used to illustrate the concept, and a shorter or longer period may be used instead.
It is possible to broadcast other data contained in Subframes 4 and/or 5 not shown in table 29. The format of the message remains the same, only the particular page of the desired data needs to be set properly. The contents of words 3 through 10 also need to be set as described in ICD-GPS-200. Using this format, it provides maximum compatibility for future expansion to include other data in subframes 4 and 5 not shown in table 30 or ICD-GPS-200.
Table 30: Mapping of Almanac, Health, Iono, and UTC Data to Subframe Number and Page Number
|
Data Type |
Subframe |
Page(s) |
|
Almanac Data (SV1 – 24) |
5 |
1 – 24 |
|
Almanac Data (SV25 – 32) |
4 |
2, 3, 4, 5, 7, 8, 9, 10 |
|
SV Health (SV1 – 24) |
5 |
25 |
|
SV Health (SV25 – 32) |
4 |
25 |
|
Iono/UTC Corrections |
4 |
18 |
Annex A (informative):
Overview of Broadcast Assistance for E-OTD and GPS
This annex presents an overview of the functionality and requirements for broadcasting assistance information for GPS and E-OTD in GSM networks. Potential impacts to other services are also described.
A.1 General
The E-OTD and GPS assistance information may be broadcast over the SMSCB service. The SMSCB DRX service is used to forecast the occurrences of the broadcast messages. The E-OTD and GPS broadcasts are independent of each other, have own SMSCB message identifiers and are broadcast on the demand of the characteristics of the E-OTD and GPS. In the network side, the SMLC is responsible for gathering the information, constructing the broadcast messages and ciphering a part of the message, if necessary. The SMLC also maintains the deciphering keys that MS requests with MO-LR. The deciphering keys are location area specific.
SMSCB messages can be received when MS is in idle mode. When MS is in dedicated mode the same information that was received in idle mode via broadcast channel may be requested by MS via point-to-point messaging.
A.2 E-OTD Assistance Broadcast
The information that is broadcast for E-OTD assistance is used in MS-based E-OTD to help the MS measure neighbour BTSs and compute its own position. The broadcast message is built so that it has always a fixed length of 82 octets, which is the size of one SMS Cell Broadcast (SMSCB) message. The information elements are scalable according to the number of neighbour BTSs and the amount of sectored channels.
In general, the following information is included in a broadcast E-OTD assistance message:
– Reference Time.
– Neighbour Channel Time Slot Scheme.
– Information about sectored neighbour channels.
– Neighbour channel 51 Multiframe Offset values.
– Neighbour channel BCC values.
– RTD Drift Factor values (ciphered if active).
– Neighbour channel RTD values (ciphered if active).
– Serving cell and neighbour cell location information (ciphered if active).
The system information message that is received in idle mode contains the neighbour channel information. The E-OTD SMSCB message refers to this system information neighbour list so that there is indication which neighbours in the system information neighbour list are included in the broadcast message. The neighbour channel RTD values, serving cell location and neighbour cell location information may be ciphered.
Based on the information in the broadcast message and the E-OTD measurements done by MS, MS is capable to calculate its position. MS that is not capable to calculate its position itself may receive the SMSCB messages and use the unciphered contents to help the synchronization to the neighbour channels.
Most information contained in the E-OTD broadcast message is static. However, the RTD values change relatively often due to the drift in unsynchronized BTS clocks. The duration of validity of RTD values will affect the location accuracy calculated by MS. The RTD update rate is a function of BTS clock stability and required location accuracy from the operator and may be specified by the operator.
A.3 GPS Assistance Broadcast
Broadcast DGPS Data
The main content of the broadcast message for GPS assistance is DGPS corrections. This information is used in MS-based GPS positioning to improve the accuracy of the position result. Some background information for DGPS broadcast is presented in this subclause. Requirements on the GSM network for broadcasting DGPS corrections are also discussed.
In good signal environments, the primary determinant of position accuracy for GPS is the intentional degradation of the GPS satellite clocks, known as selective availability (SA). Another contributor to the error budget is unmodeled atmospheric delay. The techniques used to correct these error sources are collectively known as differential GPS (DGPS). These methods involve locating one or more reference receivers at known locations and observing the visible satellite signals. These receivers essentially solve the inverse GPS problem – find differences from the expected measurements at the known position. The accuracy of the DGPS corrections is inversely proportional to the distance from the reference location. The inaccuracy is caused by changes in the geometry and visibility of the satellite constellation. For most applications, however, the corrections are valid for receivers within a 200 km to 400 km radius of the reference station.
One noteworthy characteristic of the DGPS corrections is that they have a short time constant compared to other GPS information such as satellite ephemeris. Once a correction model is computed, its accuracy degrades over time. This is mainly due to the time-varying nature of the SA imposed on the satellite signals. The duration of validity of a set of differential corrections depends on the accuracy requirements of the user or application, but in general the corrections must be updated at least every 30 s.
The fact that DGPS corrections are valid for large areas but require frequent update make them very suitable for delivery over a GSM broadcast channel such as SMSCB. This broadcast strategy is used by other DGPS sources, such as FM broadcast stations and geostationary satellites (WAAS, EGNOS, and MSAS). However, broadcasting the DGPS corrections in the GSM network has a clear advantage over other sources. This is mainly due to the fact that GSM broadcast exploits the existing reliable data link between the GPS-capable MS and the GSM network. In the other methods, the MS must capture the DGPS information from another source and therefore pays a price in power consumption, complexity, or both.
The format used for GSM broadcast of DGPS corrections includes a list of satellites visible at a nearby reference location, the correction in the range measurement for each satellite, and the rate-of-change of the range correction. In addition, an allowance is made for adding correction differences (i.e. PRC and RRC values) for multiple copies of the GPS ephemeris, to reduce the network traffic flow. Other information includes satellite health status and a reference GPS time for the corrections. The total amount of DGPS information is 48 bits (6 octets) per satellite with 80 bits (10 octets) of overhead information. The total message size for 12 visible satellites is 82 octets, which will fit within a single SMSCB message.
Broadcast Other Data
The contents of the other broadcast GPS Assiatance Message data sets are ephemeris and clock correction, as well as almanac and other data. This information can be used by the GPS receiver integrated with MS to improve the signal acquisition time and sensitivity, to recover GPS time and to obtain Ephemeris, clock correction, UTC offset, Ionospheric delay, and Almanac data. For example, the ephemris data set may be broadcast every 90 s, and Almanac may be broadcast once every serveral hours. The mobile station which does not require E-OTD and/or DGPS assistance can wake up at 90 s intervals, download these data, and then go back to sleep. This broadcast message can assist mobile station in idle mode to acquire GPS satellites with improved sensitivity and perform GPS time recovery without point-to-point communication, therefore improving the time to the first fix and reducing the point-to-point message traffic. The message can be provided within a single SMSCB message.
A.4 Impact on Other Services
Latency
The main impact is due to latency requirements for delivery of the DGPS and E-OTD assistance information. Both the DGPS corrections and the RTD values are valid for relatively short periods of time, and must be delivered in a timely manner. Thus, the service is sensitive to delays such as buffering broadcast SMSCB messages. The Reference Time in the broadcast messages and the drift factors can be used to compensate latency.
The Ephemeris and Clock Correction data set needs to be broadcast once every 90 s. The period for broadcasting the data set is chosen to provide the entire ephemeris (three subframes) in a reasonable amount of time. For 8 satellites, it would take 12 minutes. The Almanac and Other Data data set can be broadcast every several hours. To deliver the entire data set within 6 minutes, 12 broadcasts with a 30 s rate are required. It can also be broadcast at a much slower rate. For instance, for a 20 minute rate, the data set can be delivered to the mobile station every 4 hours.
Capacity
The SMSCB used for LCS uses the basic CBCH or extended CBCH. The support of E-OTD and/or DGPS broadcast needs capacity related to broadcast message characteristics (RTD/DGPS validity). The SMSCB DRX service also needs to schedule a message that is sent once per schedule period. The maximum schedule period is 48 SMSCB message slots.
Example of capacity scenario:
– The basic CBCH uses the same physical resource as SDCCH/4 (sub channel 2) or SDCCH/8 (sub channel 2). If SMSCB service is supported in basic CBCH it occupies 1/4 of SDCCH capacity when using SDCCH/4 and 1/8 of SDCCH capacity when using SDCCH/8.
– The basic CBCH capacity is 1 SMSCB message per 2 s.
– Both DGPS and E-OTD broadcast is assumed to be once per 30 s and the Ephemeris and Almanac messages are assumed to be once per 90 s or longer (capacity is 15 SMSCB messages per 30 s).
– Schedule period is 45 (= 45 x 2 s = 90 s). If SMSCB DRX service is used for other services in SMSCB, the one SMSCB DRX schedule message per schedule period is needed to support all services:
LCS needs 2/15 + 1/45 of SMSCB capacity plus one schedule message every 90 s for delivering assistance data for both E-OTD and GPS methods.
Annex B (informative):
Example of E-OTD Assistance Data Broadcast Message
This example describes how the message is built when following neighbour cell information is enclosed into SMSCB broadcast message:
– All neighbours (1-19) from System Information Neighbour List is included into one broadcast message.
– The neighbours 1, 2, 3, 7, 8, 9, 11, 12, 13, 16, 17 and 19 are belonging to sectored BTS and following channels are in the same groups: (1, 2, 3), (7, 8, 9), (11, 12, 13) and (16, 17, 19). Serving cell channel is not belonging to sectored BTS.
– The channels belonging to sectored BTS are syncronized.
– The accuracy range is 15 km, and ciphering is active.
– The 51 Multiframe Value is included, the RTD range is 1 time slot and the RTD accuracy in 1/32 bit.
– BTS network is not syncronized.
– RTD Drift Factors are not included into message.
NOTE: There are 15 remain bits for Relative Location Values and the 15 bits are used for Relative North or East extention bits. These bits are added to Nb18 North, Nb18 East, Nb15 North, Nb15 East, Nb14 North, Nb14 East, Nb10 North, Nb10 East, Nb6 North, Nb6 East, Nb5 North, Nb5 East, Nb4 North, Nb4 East and ID4 North.. These have 8 bits and the rest have 7 bits for relative location value.
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
|---|---|---|---|---|---|---|---|---|
|
Cipher On (1) |
Cipher Key Ind (0) |
Accuracy Range MSB(010)LSB |
All Neighbours MSB(000)LSB |
Octet1 |
||||
|
Number of Neigh MSB(11) |
RTDs Present (1) |
RTD Drift Factors Present (0) |
RTD Accuracy MSB(01)LSB |
RTD Range (1) |
Sector Ind On (1) |
Octet2 |
||
|
Reference Time (MSB, bits 9-5) |
Number of Neigh (001)LSB |
Octet3 |
||||||
|
Ciphering Serial Number (MSB, bits 15-13) |
Reference Time (LSB, bits 4-0) |
Octet4 |
||||||
|
Ciphering Serial Number (bits 12-5) |
Octet5 |
|||||||
|
Time Slot Scheme Serv Cell (MSB)& Nb19-18 |
Ciphering Serial Number (bits 4-0, LSB) |
Octet6 |
||||||
|
Time Slot Scheme Nb17-10 |
Octet7 |
|||||||
|
Time Slot Scheme Nb9-2 |
Octet8 |
|||||||
|
Sectored Channels Serv Cell & Nb19-14 (0101100) |
Time Slot Scheme Nb1 LSB |
Octet9 |
||||||
|
Sectored Channels Nb13-6 (11101110) |
Octet10 |
|||||||
|
Sec Ch BTS ID4 Nb19 MSB(011)LSB |
Sectored Channels Nb5-1 (00111)LSB |
Octet11 |
||||||
|
Sec Ch BTS ID3 Nb13 MSB(01) |
Sec Ch BTS ID4 Nb16 MSB(011)LSB |
Sec Ch BTS ID4 Nb17 MSB(011)LSB |
Octet12 |
|||||
|
Sec Ch BTS ID2 Nb9 MSB(0) |
Sec Ch BTS ID3 Nb11 MSB(010)LSB |
Sec Ch BTS ID3 Nb12 MSB(010)LSB |
Sec Ch BTS ID3 (0)LSB |
Octet13 |
||||
|
Sec Ch BTS ID2 Nb7 MSB(001)LSB |
Sec Ch BTS ID2 Nb8 MSB(001)LSB |
Sec Ch BTS ID2 Nb9 (01)LSB |
Octet14 |
|||||
|
Sec Ch BTS ID1 Nb1 MSB(00) |
Sec Ch BTS ID1 Nb2 MSB(000)LSB |
Sec Ch BTS ID1 Nb3 MSB(000)LSB |
Octet15 |
|||||
|
51MF Offset Value Nb19 (MSB) |
Sync ID1 (1) |
Sync ID2 (1) |
Sync ID3 (1) |
Sync ID4 (1) |
Sec Ch BTS ID1 Nb1 (0)LSB |
Octet16 |
||
|
51MF Offset Value Nb18 (MSB) |
51MF Offset Value Nb19 (LSB) |
Octet17 |
||||||
|
51MF Offset Value Nb16 (MSB) |
51MF Offset Value Nb17 (MSB LSB) |
51MF Offset Value Nb18 (LSB) |
Octet18 |
|||||
|
51MF Offset Value Nb15 (MSB) |
51MF Offset Value Nb16 (LSB) |
Octet19 |
||||||
|
51MF Offset Value Nb14 (MSB) |
51MF Offset Value Nb15 (LSB) |
Octet20 |
||||||
|
51MF Offset Value Nb12 (MSB) |
51MF Offset Value Nb13 (MSB LSB) |
51MF Offset Value Nb14 (LSB) |
Octet21 |
|||||
|
51MF Offset Value Nb11 (MSB) |
51MF Offset Value Nb12 (LSB) |
Octet22 |
||||||
|
51MF Offset Value Nb10 (MSB) |
51MF Offset Value Nb11 (LSB) |
Octet23 |
||||||
|
51MF Offset Value Nb8 (MSB) |
51MF Offset Value Nb9 (MSB LSB) |
51MF Offset Value Nb10 (LSB) |
Octet24 |
|||||
|
51MF Offset Value Nb7 (MSB) |
51MF Offset Value Nb8 (LSB) |
Octet25 |
||||||
|
51MF Offset Value Nb6 (MSB) |
51MF Offset Value Nb7 (LSB) |
Octet26 |
||||||
|
51MF Offset Value Nb4 (MSB) |
51MF Offset Value Nb5 (MSB LSB) |
51MF Offset Value Nb6 (LSB) |
Octet27 |
|||||
|
51MF Offset Value Nb3 (MSB) |
51MF Offset Value Nb4 (LSB) |
Octet28 |
||||||
|
51MF Offset Value Nb2 (MSB) |
51MF Offset Value Nb3 (LSB) |
Octet29 |
||||||
|
BCC Nb19 (MSB) |
51MF Offset Value Nb1 (MSB LSB) |
51MF Offset Value Nb2 (LSB) |
Octet30 |
|||||
|
BCC Nb17 (MSB LSB) |
BCC Nb18 (MSB LSB) |
BCC Nb19 (LSB) |
Octet31 |
|||||
|
BCC Nb14 (MSB) |
BCC Nb15 (MSB LSB) |
BCC Nb16 (MSB LSB) |
Octet32 |
|||||
|
BCC Nb11 (MSB) |
BCC Nb12 (MSB LSB) |
BCC Nb13 (MSB LSB) |
BCC Nb14 (LSB) |
Octet33 |
||||
|
BCC Nb9 (MSB LSB) |
BCC Nb10 (MSB LSB) |
BCC Nb11 (LSB) |
Octet34 |
|||||
|
BCC Nb6 (MSB) |
BCC Nb7 (MSB LSB) |
BCC Nb8 (MSB LSB) |
Octet35 |
|||||
|
BCC Nb3 (MSB) |
BCC Nb4 (MSB LSB) |
BCC Nb5 (MSB LSB) |
BCC Nb6 (LSB) |
Octet36 |
||||
|
BCC Nb1 (MSB LSB) |
BCC Nb2 (MSB LSB) |
BCC Nb3 (LSB) |
Octet37 |
|||||
|
RTD Value Nb18 (MSB) |
Octet38 |
|||||||
|
RTD Value Nb15 (MSB) |
RTD Nb18 (LSB) |
Octet39 |
||||||
|
RTD Value Nb15 |
Octet40 |
|||||||
|
RTD Value Nb14 (MSB) |
RTD Value Nb15 (LSB) |
Octet41 |
||||||
|
RTD Value Nb10 (MSB) |
RTD Value Nb14 (LSB) |
Octet42 |
||||||
|
RTD Value Nb10 |
Octet43 |
|||||||
|
RTD Value Nb6 (MSB) |
RTD Value Nb10 (LSB) |
Octet44 |
||||||
|
RTD Value Nb6 |
Octet45 |
|||||||
|
RTD Value Nb5 (MSB) |
RTD Value Nb6 (LSB) |
Octet46 |
||||||
|
RTD Value Nb4 (MSB) |
RTD Value Nb5 (LSB) |
Octet47 |
||||||
|
RTD Value Nb4 |
Octet48 |
|||||||
|
RTD Value ID4 (MSB) |
RTD Value Nb4 (LSB) |
Octet49 |
||||||
|
RTD Value ID4 (LSB) |
Octet50 |
|||||||
|
RTD value ID3 (MSB) |
Octet51 |
|||||||
|
RTD Value ID2 (MSB) |
RTD Value ID3 (LSB) |
Octet52 |
||||||
|
RTD Value ID2 |
Octet53 |
|||||||
|
RTD Value ID1 (MSB) |
RTD Value ID2 (LSB) |
Octet54 |
||||||
|
Serv Cell Lat (MSB) |
RTD Value ID1 (LSB) |
Octet55 |
||||||
|
Serv Cell Lat |
Octet56 |
|||||||
|
Serv Cell Lat |
Octet57 |
|||||||
|
Serv Cell Long (MSB) |
Serv Cell Lat (LSB) |
Octet58 |
||||||
|
Serv Cell Long |
Octet59 |
|||||||
|
Serv Cell Long |
Octet60 |
|||||||
|
Rel North Nb18 (MSB) |
Serv Cell Long (LSB) |
Octet61 |
||||||
|
Rel East Nb18 (MSB) |
Rel North Nb18 (LSB) |
Octet62 |
||||||
|
Rel North Nb15 (MSB) |
Rel East Nb18 (LSB) |
Octet63 |
||||||
|
Rel East Nb15 (MSB) |
Rel North Nb15 (LSB) |
Octet64 |
||||||
|
Rel North Nb14 (MSB) |
Rel East Nb15 (LSB) |
Octet65 |
||||||
|
Rel East Nb14 (MSB) |
Rel North Nb14 (LSB) |
Octet66 |
||||||
|
Rel North Nb10 (MSB) |
Rel East Nb14 (LSB) |
Octet67 |
||||||
|
Rel East Nb10 (MSB) |
Rel North Nb10 (LSB) |
Octet68 |
||||||
|
Rel North Nb6 (MSB) |
Rel East Nb10 (LSB) |
Octet69 |
||||||
|
Rel East Nb6 (MSB) |
Rel North Nb6 (LSB) |
Octet70 |
||||||
|
Rel North Nb5 (MSB) |
Rel East Nb6 (LSB) |
Octet71 |
||||||
|
Rel East Nb5 (MSB) |
Rel North Nb5 (LSB) |
Octet72 |
||||||
|
Rel North Nb4 (MSB) |
Rel East Nb5 (LSB) |
Octet73 |
||||||
|
Rel East Nb4 (MSB) |
Rel North Nb4 (LSB) |
Octet74 |
||||||
|
Rel North ID4 (MSB) |
Rel East Nb4 (LSB) |
Octet75 |
||||||
|
Rel East ID4 (MSB) |
Rel North ID4 (LSB) |
Octet76 |
||||||
|
Rel North ID3 (MSB) |
Rel East ID4 (LSB) |
Octet77 |
||||||
|
Rel East ID3 (MSB) |
Rel North ID3 (LSB) |
Octet78 |
||||||
|
Rel North ID2 (MSB) |
Rel East ID3 (LSB) |
Octet79 |
||||||
|
Rel East ID2 (MSB) |
Rel North ID2 (LSB) |
Octet80 |
||||||
|
Rel North ID1 (MSB) |
Rel East ID2 (LSB) |
Octet81 |
||||||
|
Rel East ID1 (MSB LSB) |
Rel North ID1 (LSB) |
Octet82 |
||||||
Annex C (informative):
Example of GPS Assistance Data Broadcast Message
This annex gives an example of how the information IE should be packed into the GPS Assistance Data message. The example shown in table C.1 includes corrections for 12 satellites.
Table C.1: Example of a GPS Assistance Data (DGPS Correction) message with 11 satellites
|
Octet |
MSB |
LSB |
|||||||||||
|
1 |
Cipher On/Off |
Cipher Key Flag |
Ciphering Serial Number (MSB, bits 15-10) or Spare |
||||||||||
|
2 |
Ciphering Serial Number (bits 9-2) or Spare |
||||||||||||
|
3 |
BTS Clock Drift (bits 3-0) or Spare |
BTS Clock Drift Present |
GSM Time Present |
Ciphering Serial Number (bits 1-0) or Spare |
|||||||||
|
4 |
Reference Location |
||||||||||||
|
¦ ¦ |
¦ ¦ |
||||||||||||
|
9 |
Reference Location |
||||||||||||
|
10 |
FN (MSB bits 17-10) or Spare |
||||||||||||
|
11 |
FN (bits 9-2) or Spare |
||||||||||||
|
12 |
BN (MSB bits 7 – 5) or Spare |
TN (bits 3-0) or Spare |
FN (LSB bits 1–0) or Spare |
||||||||||
|
13 |
GPS TOW (MSB bits 19-17) or Spare |
BN (LSB bits 4 – 0) or Spare |
|||||||||||
|
14 |
GPS TOW (bits 16-9) |
||||||||||||
|
15 |
GPS TOW (bits 8-1) |
||||||||||||
|
16 |
N_SAT (bits 3-0) |
Correction Status/Health (bits 2-0) |
GPS TOW (LSB bit0) |
||||||||||
|
17 |
Satellite ID (Sat 1) |
UDRE (Sat 1) |
|||||||||||
|
18 |
IODE (Sat 1) |
||||||||||||
|
19 |
PRC (Sat 1 – MSBs, 7 – 0) |
||||||||||||
|
20 |
PRC (Sat 1 – MSBs, 7 – 4) |
RRC (Sat 1 – LSBs, 3-0) |
|||||||||||
|
21 |
RRC (Sat 1 – LSBs, 7 – 4) |
Delta PRC (Sat 1 – LSBs, 3-0) |
|||||||||||
|
22 |
Delta PRC (Sat 1 – MSBs, 7 – 4) |
Delta RRC (Sat 1) |
|||||||||||
|
¦ ¦ |
¦ ¦ |
||||||||||||
|
77 |
Satellite ID (Sat 12) |
UDRE (Sat 12) |
|||||||||||
|
78 |
IODE (Sat 12) |
||||||||||||
|
79 |
PRC (Sat 12 – MSBs, 7 – 0) |
||||||||||||
|
80 |
PRC (Sat 12 – MSBs, 7 – 4) |
RRC (Sat 12 – LSBs, 3-0) |
|||||||||||
|
81 |
RRC (Sat 12– LSBs, 7 – 4) |
Delta PRC (Sat 12 – LSBs, 3-0) |
|||||||||||
|
82 |
Delta PRC (Sat 12 – MSBs, 7 – 4) |
Delta RRC (Sat 12) |
|||||||||||
Annex D (informative):
Change History
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2016-01 |
– |
– |
– |
Rel-13 version created based on v12.0.0 |
13.0.0 |
||
|
2017-03 |
RP-75 |
– |
– |
– |
– |
Release 14 version (frozen at TSG-75) |
14.0.0 |
|
2018-06 |
RP-80 |
– |
– |
– |
– |
Release 15 version (frozen at TSG-80) |
15.0.0 |
|
2020-07 |
RP-88e |
– |
– |
– |
– |
Upgrade to Rel-16 version without technical change |
16.0.0 |
|
2022-03 |
RP-95e |
– |
– |
– |
– |
Upgrade to Rel-17 version without technical change |
17.0.0 |