This section describes GPEH data files.
The recorded data consists of Layer 3 protocol messages, in this description called inter-node events, and internal events. The protocol messages are taken from the RNC external protocol interfaces in ASN.1-
encoded format and converted to bit-packed binary format. The internal event is also stored in bitpacked binary format.
The events are collected in GPEH data files, also called GPEH ROP files. The events are written to file in the order they appear in the buffers and are not ordered chronologically. For each 15-minute ROP period, the following two types of file are generated:
Main File The main file contains administrative information about the GPEH recording and links to subfiles. The file storage location of the main file is decided by the attribute performanceDataPath on the CPP managed object ManagedElementData. Default value at node start up is either /p001200/ or /p001300, depending on whether the O&M MP functionality executes on board 12 or 13 in the main subrack at start up. It is not recommended to change this value. Subfile A subfile contains recorded events for all active scanners. The
main file contains link records which points out the file path to the subfiles.
One main file generated on the O&M MP, one subfile on the O&M MP, and one subfile per Module MP conclude each ROP. Each file has a unique name according to the file name convention described in Table 12.
Table 12 GPEH File Naming
File Name:
Main file: <Type><Date>.<StartTime>-<EndTime>_gpehfile:2.lnk.gz Subfile: <Type><Date>.<StartTime>-<EndTime>_GPEH.lnk.gz
Type Always set to "A" - single Network Element and single recording/granularity period
Date YYYYMMDD
Starttime HHMM
Endtime HHMM
For an example of a file name, see Example 1. Example 1 GPEH File Name
Main File: A20081128.1515-1530_gpehfile:2.lnk.gz Subfile: A20081128.1515-1530_GPEH.lnk.gz
4.1 Structure
Each file comprises the following records:
Header Administrative information about the file. Recording Scope of the recording.
Protocol The name and version of the protocol from which messages can be recorded.
Body The body contains event records. The event record contains details about inter-node events and RNC-internal events. It is only the subfile that has a body record.
Link A link from the main file to a GPEH subfile on another MP.
Footer Administrative information about the time of normal termination of the ROP file.
Error Contains the time and cause of an abnormal termination of a recording. The error record replaces the footer record if the file is terminated abnormally.
The GPEH data file structure and the relation between the main file and the subfiles are displayed in Figure 1.
The file starts with a header record followed by one or more recording records, one for each active scanner.
Then there are a number of protocol records. They appear in the file regardless of whether there are messages from that protocol in the file. Then there are a number of optional link records, each pointing to a subfile, which contains a body record.
Finally, the footer record appears, unless the main file is terminated abnormally. In case of abnormal termination an error record replaces the footer record.
4.2 Records
This section describes the GPEH data file records. 4.2.1 Header
Details of the header record layout are provided in Table 13.
Table 13 Header Record Layout Details
Pos Description Size (bytes) Type Value/Range 0 Record Length 2 unsigned short [2..65535] 1 Record Type 1 unsigned char 0
2 File Format Version 5 char[] (1)
3 Year (four digits) 2 unsigned short [2000..]
4 Month 1 unsigned short [1..12]
5 Day 1 unsigned short [1..31]
6 Hour 1 unsigned short [0..23]
7 Minute 1 unsigned short [0..59]
8 Second 1 unsigned short [0..61](2)
9 NE user label 200 char[] The value of the
attribute
’userLabel’ of the Managed Object (MO)
’ManagedElement’
10 NE logical name 200 char[]
The value of the attribute ’logicalName’ of the Managed Object (MO) ’ManagedElement’ 11 File information version 5 char[] (3)
(1) File format version "X-Y" should be updated as follows: Increment "X", whenever a new record is introduced to the file format - Incompatible change of the WRAN product release. Increment "Y", whenever a change is made to the existing record structure for a product - Incompatible change of the WRAN product release. In W10 the file format version (FFV) is according to the following: W10.0 and on: FFV= 7-1 Note: Addition of new events, measurements or event attributes will NOT cause a change to file format version.
(2) Range 0..61 to handle leap seconds.
(3) File information Version (FIV) is represented as an ASCII string: [:SPACE:]*[A-Z]*[0- 9]*. Some samples on valid combinations of the five characters ( _ symbolizes space): ____A , ___AB , __AB1 , _AAB1 , AAAAA .
For an example of the header record, see Example 2. Example 2 Header Record
HEADER
FileFormatVersion: 7- 1
Year: 2009 Month: 1 Day: 12 Hour: 15 Minute: 15 Second: 0
NEUserLabel: ak0ru32 NetworkElementName: 032
FileInformationVersion: __AB1
4.2.2 Recording
Details of the recording record layout are provided in Table 14.
Table 14 Recording Record Layout Details
Pos Description Size (bytes) Type Value/Range 0 Record
Length 2 unsigned short [2..65535]
1 Record Type 1 unsigned
char 1
2 Filter Type 1 unsigned
char [0..2]
(1)
(1) 0 - PM recording type UETR, 1 - PM recording type CTR, 2 - PM recording type GPEH (2) Holds the filter setting for this scanner. Recording type UETR: Holds IMSI value as an ASCII string, Recording type CTR: Holds Access Cell Identity as an ASCII string. Cells are identified using the LDN of the access cell, Recording type GPEH: Holds UE fraction and recording area (cells). The filter setting included as a list of name-value pairs, the list is represented as a sequence of NULL-terminated strings as: String: 0 - name 0, 1 - value 0, 2 - name 1, 3 - value 1, . . n - name n/2, n + 1 - value n/2
For an example of the recording data record, see Example 3. Example 3 Recording Data Record
RECORDING
UE_FRACTION: 1000 CELL:
ManagedElement=1,RncFunction=1,UtranCell=201093
4.2.3 Protocol
Details of the protocol record layout are provided in Table 15.
Table 15 Protocol Record Layout Details
Pos Description (bytes)Size Type Value/Range
0 Record length 2 unsigned short [2..65535]
1 Record Type 1 unsigned char 2
2 Protocol id 1 unsigned char [0..7](1)
3 Protocol name 50 char[] (2)
4 Object Identifier 30 char[] (3)
(1) The "Protocol id" represented as: 0=RRC "3GPP TS 25.331 V8.6.0", 1=NBAP "3GPP TS 25.433 V8.4.0", 2=RANAP "3GPP TS 25.413 V7.8.0", or 4=RNSAP "3GPP TS 25.423 V7.7.0", 5=INTERNAL_EVENT (RNC internal protocol ID including RNC internal events and RNC internal measurements), 6=PCAP "3GPP TS 25.453 V7.6.0" or 7=SABP "3GPP TS 25.419 V6.2.0".
(2) The "Protocol name" represented as an ASCII string: RANAP, NBAP, RNSAP, RRC, PCAP, SABP or INTERNAL_EVENT.
(3) The "Object identifier" of standard ASN.1 data type definition for the messages from this protocol, represented as an ASCII string: "a,b,c,d,ee,f,g,h", where: a=itu-t(0), b=identified-organization(4), c=etsi(0), d=mobileDomain(0), ee=umts-Access(20), f=modules(3), g=ranap(0),nbap(2) or rnsap(1), h=version1(1). Whereas the RRC, PCAP, SABP protocols, the "Number and Version" of the 3GPP specification is instead
represented as an ASCII string: RRC: "3GPP TS 25.331 V8.6.0", PCAP: "3GPP TS 25.453 V7.6.0", SABP: "3GPP TS 25.419 V6.2.0", or "N/A" if Protocol ID="5" (INTERNAL_EVENT).
Example 4 Protocol Record
PROTOCOL
Protocol id: 1 Protocol name: NBAP
Object identifier: 0.4.0.0.20.3.2.1
4.2.4 Body
The body record can contain event records.
4.2.4.1 Event
The event record holds an event of any kind (inter-node or RNC-internal events).
Details of the event record layout are provided in Table 16.
Table 16 Event Record Layout Details
Pos Description (bytes)Size Type Value/Range
0 Record Length 2 unsigned short [2..65535]
1 Record Type 1 unsigned char 4
2 Bitpacked part - unsigned char[]
Bitpacking
All information in the event record, except for the Record Length and Record Type fields, are bit-packed in order to save space. The bit- packed part is organized as a sequence of bitfields of variable length. The length of the bit-packed part is always a multiple of 32-bit words. Unused bits in the last word are set to zero. The most significant bit (msb) appears first in each bitfield. The outline of the bit-packed part of the event records is shown in Figure 2.
Figure 2 Bitpacked Part of Event Record
The bit-packed part is further divided in common fields, included for all events, and specific fields, specific per event. The common parts are
described in Table 17. The Pos column in the table only indicates the order in which the bit-fields appear.
Table 17 Common Part in Bitpacked Layout
Pos Description (bits)Size Encoding Value/Range
0 Scanner ID 24 binary integer [0,1](1)
1 Hour 5 binary integer [0..23]
2 Minute 6 binary integer [0..59]
3 Second 6 binary integer
[0..61] The value 61 represents a leap second.
4 Millisecond 11 binary integer [0..999]
5 Event ID(2) 11 binary integer
(1) The scanner ID field consists of a sequence of bits (24 bits), each bit corresponding to a particular scanner ID (0-23 scanners GPEH, 0-15 scanners UETR, 0-1 scanners CTR). “0” is used in the corresponding bit location to indicate when an event is NOT part of a particular scanner. “1” will be used in the corresponding bit location to indicate that an event is part of a particular scanner. Note that the same event could be part of one, several, or all scanners. Event presence for each scanner will be indicated with “1” in the scanner ID field.
(2) Unique identifier for an RNC event.
The RNC-internal event-specific fields are bit-packed, see Section 3 for bitpacking for each parameter. Additional common fields in the
bitpacked part of the event record for RNC external and RNC internal events are listed in Table 18.
Table 18 Additional Common Fields in Bitpacked Part of an Event Record
Pos Description Size Type Value/Range(1)
0 ueContextId 16 bits binary integer [-1 .. 2 15 - 1](2)
1 rncModuleId 7 bits binary integer [1 .. 26 – 1](3)
2 cellID1 17 binary integer [0...65535]
3 rncID1 13 binary integer [0..4095]
4 cellID2 17 binary integer [0...65535]
5 rncID2 13 binary integer [0..4095]
6 cellID3 17 binary integer [0...65535]
7 rncID3 13 binary integer [0..4095]
8 cellID4 17 binary integer [0...65535]
(1) All bitpacked parameters are represented with an additional bit. The additional bit, which is the most significant bit, indicates whether the reported value is valid or not. A parameter not having a valid value to report at the time of event reporting is filled with 1's (including the additional bit) also referred to as the value EVENT_VALUE_INVALID. (2) EVENT_VALUE_INVALID used for messages not related to a specific UE.
(3) EVENT_VALUE_INVALID used for messages not related to a specific RNC Module identity.
The RNC external event specific fields to be bit packed are listed in Table 19.
Table 19 External Event Specific Fields
Pos Description Size Type Value/Range
0 PDU type 5 bits binary integer [1..9](1)
1 Protocol id 4 bits binary integer [0..4](2)
2 Direction 2 bits binary integer [0..1](3)
3 Message length 12 bytes unsigned short [0..x](4)
4 Encoded message - unsigned char[] [message length (bytes) x 8 bits](5)
Padding bits All unused bits in the last word (32- bit word) are set to zero (1) 1:DL-DCCH-MSG, 2:UL-DCCH-MSG, 3:DL-CCCH-MSG, 4:UL-CCCH-MSG, 5:PCCH-
MSG, 6:DL-SHCCH-MSG, 7:UL:SHCCH-MSG, 8:BCCH-FACH-MSG, 9:BCCH-BCH-MSG (DL = Downlink, UL = Uplink, MSG = Message, DCCH = Dedicated Control Channel, CCCH = Common Control Channel, PCCH = Paging Control Channel, SHCCH = Shared Control Channel, BCCH = Broadcast Control Channel), EVENT_VALUE_INVALID used for messages where no PDU type is available.
(2) Protocol ID as previously defined in protocol record.
(3) The value 0 indicates received, and the value 1 indicates sent. (4) x is the length in bytes of the following encoded protocol message.
(5) Actual protocol message, encoded as transferred on the external RNC interface and previously defined in the protocol record. For the encoding format, refer to the protocol specifications.
For an example of the event record, see Example 5 for RNC-internal events, and Example 6 for inter-node events..
Example 5 Event Record, RNC-Internal Event
EVENT
Hour: 15 Minute: 19 Second: 57 Millisecond: 104 Event_ID: 444
UE_CONTEXT: Not Applicable RNC_MODULE_ID: Invalid C_ID_1: Not Applicable RNC_ID_1: Not Applicable C_ID_2: Not Applicable RNC_ID_2: Not Applicable C_ID_3: Not Applicable RNC_ID_3: Not Applicable C_ID_4: Not Applicable RNC_ID_4: Not Applicable RNC_MP_ID: 6
EVENT_TRIGGER: 57
AFFECTED_SCANNER_TYPE: Invalid
Example 6 Event Record, Inter-Node event
EVENT
Hour: 15 Minute: 26 Second: 51 Millisecond: 422 Event_ID: 145 UeContextID: 268 RncModuleID: 4 C_ID_1: 1093 RNC_ID_1: 32 C_ID_2: 1093 RNC_ID_2: 32 C_ID_3: 1093 RNC_ID_3: 32 C_ID_4: 1093 RNC_ID_4: 32 PDU-type: -1 ProtocolID: 1 Direction:RECEIVED Message length: 34 EncodedMessage:
value NBAP-PDU ::= initiatingMessage : { procedureID { procedureCode 18, ddMode common }, criticality ignore, messageDiscriminator dedicated, transactionID shortTransActionId : 57, value DedicatedMeasurementReport : { protocolIEs { { id 44, criticality ignore, value CRNC-CommunicationContextID : 189 }, {
id 133, criticality ignore, value MeasurementID : 300 }, { id 67, criticality ignore, value DedicatedMeasurementObjectType-DM-Rprt : all-RL : { rL-InformationList-DM-Rprt { { id 202, criticality ignore, value RL-InformationItem-DM- Rprt : { rL-ID 0, dedicatedMeasurementValueInformation measurementAvailable : { dedicatedmeasurementValue transmittedCodePowerValue : 69 } } } } } } } } } 4.2.5 Link Details of the link record layout are provided in Table 20. Table 20 Link Record Layout Details Pos Description (bytes)Size Type Value/Range 0 Record Length 2 unsigned short [2..65535]
1 Record Type 1 unsigned char 8
2 File Path (1) 256 char[]
(1) Absolute path, including the name of the file in the node filesystem.
For an example of the link record, see Example 7. Example 7 Link Record
LINK
file: /p001400/A20031128.1515-1530_GPEH.lnk
4.2.6 Footer
Details of the footer record layout are provided in Table 21.
Table 21 Footer Record Layout Details
Pos Description (bytes)Size Type Value/Range
0 Record Length 2 unsigned short [2..65535]
1 Record Type 1 unsigned char 7
2 Year (four digits) 2 unsigned short [2000..]
3 Month 1 unsigned char [1..12]
4 Day 1 unsigned char [1..31]
5 Hour 1 unsigned char [0..23]
6 Minute 1 unsigned char [0..59]
7 Second 1 unsigned char
[0..61] The value 61 represents a leap second.
For an example of the footer record, see Example 8. Example 8 Footer Record
FOOTER
Year:2003 Month: 11 Day: 28 Hour: 15 Minute: 30 Second: 0
4.2.7 Error
The error record is included only if the file is terminated abnormally in the RNC. It contains the cause and the time of the abnormal
termination.
Details of the error record layout are provided in Table 22.
Table 22 Error Record Layout Details
Pos Description (bytes)Size Type Value/Range
0 Record Length 2 unsigned short [2..65535]
2 Hour 1 unsigned char [0..23]
3 Minute 1 unsigned char [0..59]
4 Second 1 unsigned char
[0..61] The value 61 represents a leap second.
5 Millisecond 2 unsigned short [0..999]
6 Error type 1 unsigned char [0..4](1)
(1) Value: 0 - File system error, 1 - Communication error (=restart), 2 - Not used, 3 - Not used, 4 - Other
For an example of the error record, see Example 9. Example 9 Error Record
ERROR
Hour: 15 Minute: 5 Second: 52 Millisecond: 164 ErrorType: Other