User Manual
Table Of Contents
- BGAN XL Radio Module
- Record of Revisions
- Table of contents
- Chapter 1 About this manual
- Chapter 2 Introduction to BGAN
- Chapter 3 Product overview
- Chapter 4 System description
- Chapter 5 Product specifications
- Chapter 6 Startup & configuration
- Chapter 7 Data interfaces
- Chapter 8 Control interface
- Chapter 9 RF & RF control interface
- Chapter 10 Test & diagnostics
- Chapter 11 Terminal support
- Chapter 12 Use cases
- Chapter 13 Applications
- Chapter 14 Type approval
- About this manual
- Introduction to BGAN
- Product overview
- System description
- 4.1 Introduction to the BGAN XL Radio Module
- 4.2 BGAN XL Radio Module interface overview
- 4.3 Integrating the BGAN XL Radio Module
- 4.4 High-level terminal system design
- Product specifications
- 5.1 General precautions
- 5.3 Mounting considerations
- 5.4 Environmental specifications
- 5.5 Connector specifications
- 5.6 Electrical characteristics
- 5.7 Interface descriptions
- Startup & configuration
- 6.1 Start-up
- 6.1.1 Overview
- 6.1.2 Start-up Procedure (step by step)
- Figure 6-3: Start-up sequence of the BGAN XL Radio Module.
- 6.1.2.1 Step #1 - Starting (booting)
- 6.1.2.2 Step #2 - Internal POST
- 6.1.2.3 Step #3 - Configuration (static)
- 6.1.2.4 Step #4 - Service mode
- 6.1.2.5 Step #5a - Extended POST
- 6.1.2.6 Step #5b - Calibration
- 6.1.2.7 Step #6 -Configuration (dynamic)
- 6.1.2.8 Step #7 -BGAN Waveform mode
- 6.2 General use
- 6.3 Parameter overview
- 6.4 System
- Figure 6-4: Parameter hierarchy for system parameters.
- 6.4.1 BGAN XL Radio Module status
- 6.4.2 Software versions
- 6.4.3 BGAN XL Radio Module temperature
- 6.4.4 Software updated
- 6.4.5 Power management / SDM sleep
- 6.4.6 TSI/PCM bus configuration
- 6.4.7 Terminal serial number (FOR INTERNAL USE)
- 6.4.8 RM serial numbers
- 6.4.9 MAC address
- 6.4.10 BOM versions
- 6.4.11 Errorlog entries (FOR INTERNAL USE)
- 6.4.12 Platform type (FOR INTERNAL USE)
- 6.4.13 Limitation on the background data rate
- 6.4.14 HTTP Interface
- 6.5 Interface
- 6.6 Functionality
- Figure 6-6: Parameter hierarchy for functionality parameters
- 6.6.1 Radio silence
- 6.6.2 Satellite selection
- 6.6.3 Doppler correction
- 6.6.4 Fast signal-to-noise reports
- 6.6.5 Drift distribution
- 6.6.6 AMBE encoding
- 6.6.7 Call waiting
- 6.6.8 FEC decoding
- 6.6.9 BPLT parameters
- 6.6.10 AAGW timestamp
- 6.6.11 Suspend mode
- 6.6.12 Buffering on streaming connections
- 6.6.13 HDR bit rate ramp up
- 6.6.14 SMS
- 6.6.15 Satellite table
- 6.6.16 Static route
- 6.7 Status
- Figure 6-7: Parameter hierarchy for status parameters.
- 6.7.1 Receiver AGC level
- 6.7.2 Reference clock
- 6.7.3 Satellite information
- 6.7.4 IAI-2 status information
- 6.7.5 Satellite coverage
- 6.7.6 GPS policy
- 6.7.7 Connection status
- 6.7.8 Navigational information (aeronautical) (FOR INTERNAL USE)
- 6.7.9 Data segregation (aeronautical) (FOR INTERNAL USE)
- 6.7.10 S-Band, antenna mute detector (FOR INTERNAL USE)
- 6.8 Control
- Figure 6-8: Parameter hierarchy for control parameters.
- 6.8.1 BGAN Class
- 6.8.2 Product Type
- 6.8.3 BGAN IMEI Number
- 6.8.4 BGAN capabilities
- 6.8.5 Receiver input power (FOR INTERNAL USE)
- 6.8.6 Transmitter output power
- 6.8.7 ATC activation
- 6.8.8 Sky-scan (Check power)
- 6.8.9 Sky-scan (Check waveform)
- 6.8.10 UMTS operation mode
- 6.8.11 S-Band (FOR INTERNAL USE)
- 6.8.12 S-Band antenna mute detector (FOR INTERNAL USE)
- 6.8.13 Synchronous Serial Link (FOR INTERNAL USE)
- 6.9 Connection types
- 6.10 Support
- 6.11 Factory (FOR INTERNAL USE)
- 6.12 Settings (FOR INTERNAL USE)
- 6.12.1 Flash parameters related to modem operation
- Figure 6-12: Parameter hierarchy for flash parameters.
- 6.12.1.1 Tx burst control
- 6.12.1.2 Intermediate receiver frequency
- 6.12.1.3 Intermediate transmitter frequency
- 6.12.1.4 Internal power saving
- 6.12.1.5 Modem state
- 6.12.1.6 Rx gain control
- 6.12.1.7 Reference clock
- 6.12.1.8 Early termination of the turbo decoder
- 6.12.1.9 FPGA debug mux
- 6.12.1.10 BUTTS setting
- 6.12.1.11 S-Band SSR Generator
- 6.12.2 Parameters related to extended POST (FOR INTERNAL USE)
- 6.12.1 Flash parameters related to modem operation
- 6.1 Start-up
- Data interfaces
- 7.1 Protocol overview for the data interface
- 7.2 Physical layer
- 7.3 Network layer
- 7.5 Circuit switched services
- 7.5.1 Voice and CS data calls
- 7.5.2 SIP registering and authentication
- 7.5.3 BGAN call type signalling
- 7.5.4 BGAN call priority signalling
- 7.5.5 Network and BGAN XL Radio Module cause codes
- 7.5.6 Supplementary services
- 7.5.7 RTP payloads
- 7.5.8 ISDN Q.931 bearer capabilities
- 7.5.9 ISDN data via the PCM bus
- 7.5.10 ISDN data via RTP
- 7.5.11 Supplementary services interrogation, registration and invocation
- 7.5.12 Short Message Service (SMS)
- 7.5.13 Supported SIP RFCs
- 7.5.14 List of circuit-switched cause codes
- Table 7-11: List of circuit-switched cause codes (UMTS Call Control)
- Table 7-12: List of circuit-switched cause codes (Internal cause codes from the RM)
- Table 7-13: Cause codes received from RAN (SDM cause codes added with 0x00086400)
- Table 7-14: Cause codes from ‘UMTS specific cause values for mobility management’ in 3GPP TS24.008 section 10.5.3.6 added with 0x00034000
- Table 7-15: Cause codes from the RM, also used for packet-switched
- 7.6 Packet switched services
- 7.6.1 Brief introduction to PDP contexts and Traffic Flow Templates
- 7.6.2 The PPPoE-to-PDP-family mapping
- 7.6.3 PPPoE service names
- 7.6.4 Manipulating secondary PDP contexts and QoS parameters
- 7.6.5 List of AT commands for manipulating PDP family QoS
- 1. A primary PDP context with cid 2 is created.
- 2. A PDP context with cid 2 is configured as a background connection.
- 3. A secondary PDP context with cid 5 is created, with primary PDP context with cid 2 as its “parent”.
- 4. This secondary PDP context (cid 5) is configured as a Streaming 32 connection with a QoS of 32 Kbit/s constant bit rate.
- 5. A TFT is set up for PDP context with cid 5 with identifier 1, evaluation precedence 1, sending everything with IP protocol number 1 (ICMP traffic) across this PDP context.
- 6. Finally the PDP contexts are activated.
- 7.6.6 Link metrics monitoring via PPPoE PADQ message
- 7.6.7 List of packet-switched cause codes
- Table 7-17: List of packet-switched cause codes (GPRS specific)
- Table 7-18: Internal cause codes from the RM
- Table 7-19: Cause codes received from RAN (SDM cause codes added with 0x00086300)
- Table 7-20: Cause codes from ‘UMTS specific cause values for mobility management’ in 3GPP TS24.008 section 10.5.5.14 added with 0x00024000
- Table 7-21: Cause codes from the RM, also used for circuit-switched
- 7.7 Management services
- 7.7.1 HTTP interface
- 7.7.1.1 Software upload
- 7.7.1.2 Diagnostic report
- 7.7.1.3 RM configuration, status and notification subscription
- Table 7-22: Currently implemented HTTP return codes
- Table 7-23: Parameters for storage domains and data types
- Table 7-24: Reading the contents of a parameter (example)
- Table 7-25: Read setting HTTP header field Content types
- 1. Client sends notification request
- 2. Client timeout
- 3. Client re-sends notification request
- 4. Client timeout
- 5. Client re-sends notification request
- 6. BGAN XL Radio Module sends back a HTTP response
- 7. Client continues processing
- 7.7.2 Syslog interface
- 7.7.3 AT shell
- 7.7.4 Telnet
- 7.7.5 Data tunnel
- 7.7.6 USIM
- 7.7.1 HTTP interface
- 7.8 Test-specific protocols
- 7.9 TSI/PCM interface
- Control interface
- 8.1 Terminology
- 8.3 Link layer
- 8.4 Framing layer
- 8.4.1 Format of the service data unit (SDU)
- 8.4.2 Priority transfer
- 1. Higher priority SDUs will be selected before lower priority SDUs.
- 2. If two or more SDUs with the same priority are waiting for transmission, the framing layer selects the next SDU using the FIFO principle.
- 3. Transmission of lower priority fragmented SDUs will be suspended if higher priority SDUs are submitted for transmission.
- 4. A PDU transmission cannot be interrupted by another PDU, regardless of priority.
- 8.4.3 SDU fragmentation
- 8.5 Application layers
- 8.5.1 Overview
- 8.5.2 Management protocol
- 8.5.2.1 Overview
- 8.5.2.2 Message flow
- 8.5.2.3 Error handling
- 8.5.2.4 Operation management
- 8.5.2.5 Configuration access
- Table 8-8: MSG_CONFIG_READ_REQ data format
- Table 8-9: MSG_CONFIG_READ_REQ data fields
- Table 8-10: MSG_NACK cause codes returned by a MSG_CONFIG_READ
- Table 8-11: MSG_CONFIG_READ_RESP data format
- Table 8-12: MSG_CONFIG_READ_RESP data fields
- Table 8-13: MSG_CONFIG_WRITE_REQ data format
- Table 8-14: MSG_CONFIG_WRITE_REQ data fields
- Table 8-15: MSG_NACK cause codes returned by a MSG_CONFIG_WRITE_REQ
- Table 8-16: MSG_CONFIG_NOTIFY_REQ data format
- Table 8-17: MSG_CONFIG_NOTIFY_REQ data fields
- Table 8-18: MSG_NACK cause codes returned by a MSG_CONFIG_NOTIF_REQ
- Table 8-19: MSG_CONFIG_NOTIFY data format
- Table 8-20: MSG_CONFIG_NOTIFY data fields
- Table 8-21: MSG_CONFIG_NOTIFY_DATA data format
- Table 8-22: MSG_CONFIG_NOTIFY_DATA data fields
- 8.5.2.6 Event reporting
- 8.5.2.7 File transfer (FOR INTERNAL USE)
- Figure 8-13: File read message flow
- Figure 8-14: Data block timeout handling example
- Table 8-28: MSG_TFTP_RRQ data format
- Table 8-29: MSG_TFTP_RRQ data fields
- Table 8-30: MSG_TFTP_DATA data format
- Table 8-31: MSG_TFTP_DATA data fields
- Table 8-32: MSG_TFTP_ACK data format
- Table 8-33: MSG_TFTP_ACK data fields
- 8.5.2.8 Power management
- Table 8-34: MSG_SUSPEND_REQ data format
- Table 8-35: MSG_SUSPEND_REQ data fields
- Table 8-36: MSG_SUSPEND_ABORT data format
- Table 8-37: MSG_SUSPEND_ABORT data fields
- Table 8-38: MSG_POWERDOWN data format
- Table 8-39: MSG_POWERDOWN data fields
- Table 8-40: MSG_REBOOT data format
- Table 8-41: MSG_REBOOT data fields
- Table 8-42: MSG_RESET data format
- Table 8-43: MSG_RESET_REQ data fields
- 8.5.2.9 General messages
- 8.5.2.10 Aero-specific management
- 8.5.2.11 Security management (FOR INTERNAL USE)
- 8.5.2.12 Bootloader security
- 8.5.3 USIM
- 8.5.4 Navigation protocol
- 8.5.5 Antenna pointing protocol
- 8.5.5.1 Message overview
- 8.5.5.2 Satellite table
- 8.5.5.3 State transition machine
- Figure 8-22: State transition machine
- 1. STATE_WAIT_START_SKYSCAN
- 2. START_SKY_SCAN
- 3. STATE_WAIT_POWER
- 4. STATE_WAIT_WAVEFORM
- 5. STATE_NORMAL_OPERATION
- 1. High power amplifier not ready
- 2. No signal found on RF link
- 3. State illegal. State field indicate the illegal state
- 4. Not rejected
- 5. CRC failed, signal found but signal strength too weak.
- 8.5.5.4 MSG_BGAN_SKYSCAN_ALLOWED
- 8.5.5.5 MSG_BGAN_SKYSCAN_ALLOWED_RESP
- 8.5.5.6 MSG_BGAN_START_SKYSCAN
- 8.5.5.7 MSG_BGAN_SKYSCAN_RESULT
- 8.5.5.8 MSG_BGAN_SKYSCAN_RESULT_RESP
- 8.5.5.9 MSG_BGAN_CHECK_POWER
- Figure 8-23: Check power message flow
- Table 8-80: MSG_BGAN_CHECK_POWER data format
- Table 8-81: MSG_BGAN_CHECK_POWER data fields
- 1. First the receiver is tuned to the first specified SDM channel number. Legal channel numbers are received in MSG_BGAN_START_SKYSCAN.
- 2. After a settling period of 6 ms the RM initiates an estimation of the channel power. Two channel power estimates are calculated; the wide estimate is calculated in a 36 kHz bandwidth and the narrow estimate is calculated in a 14 kHz bandwidth.
- 3. After approximately 30 ms the RM will have estimated the channel power in a narrow and a wide bandwidth.
- 4. Steps 1 and 2 are repeated until the channel power of all the requested frequencies has been estimated.
- 5. When this request is carried out the power estimates are returned with the response: MSG_BGAN_CHECK_POWER_RESP.
- 8.5.5.10 MSG_BGAN_CHECK_POWER_RESP
- 8.5.5.11 MSG_BGAN_CHECK_WAVEFORM
- Figure 8-25: Check waveform message flow
- Table 8-86: MSG_BGAN_CHECK_WAVEFORM data format
- Table 8-87: MSG_BGAN_CHECK_WAVEFORM data fields
- 1. First the receiver is tuned to the specified L-band frequency.
- 2. After a settling period of 6 ms the BGAN XL Radio Module initiates an initial acquisition (due to the unknown frequency offset of the global channel).
- 3. The BGAN XL Radio Module now begins to estimate a coarse frequency offset using the assumption that a F80T025Q1B bearer is present.
- 4. After 122 ms a fairly good estimate of the coarse frequency offset will be available and the BGAN XL Radio Module begins the acquisition of the bearer (searching for known patterns).
- 5. The outcome of this acquisition is either unsuccessful or successful:
- 6. In case of a successful acquisition, subsequently CNo reports (MSG_BGAN_WAVEFORM_CNO) will now be delivered every 80 ms until acquisition fails (e.g. due to poor signal quality) or the BGAN XL Radio Module is given new instructions.
- 8.5.5.12 MSG_BGAN_CHECK_WAVEFORM_RESP
- 8.5.5.13 MSG_BGAN_SKYSCAN_RESTART
- 8.5.5.14 MSG_BGAN_SKYSCAN_RESTART_RESP
- 8.5.5.15 MSG_BGAN_WAVEFORM_CN0
- 8.5.6 Abnormality
- 8.5.7 Data tunnel
- 8.5.8 Debug shells
- 8.5.9 Extended POST
- 8.5.9.1 RF control interface
- Figure 8-29: RF Control Interface Extended POST protocol example
- Table 8-104: MSG_EXT_POST_RF_CONTROL data format
- Table 8-105: MSG_EXT_POST_RF_CONTROL data fields
- Table 8-106: MSG_EXT_POST_RF_CONTROL_RESP data format
- Table 8-107: MSG_EXT_POST_RF_CONTROL_RESP data fields
- Table 8-108: MSG_EXT_POST_RF_CONTROL_NACK data format
- Table 8-109: MSG_EXT_POST_RF_CONTROL_NACK data fields
- Table 8-110: MSG_EXT_POST_RF_CONTROL_NACK cause codes
- 8.5.9.1 RF control interface
- 8.5.10 Continuous Transmission
- RF & RF control interface
- 9.1 RF interface
- 9.1.1 Transmission timing
- 9.1.2 Output power (Tx)
- 9.1.2.1 Nominal output power
- 9.1.2.2 Gain compensation
- 1. Linear interpolation, where the gain at a certain frequency f is approximated by a straight line passing through the two data points fj and fj+1 closest to f.
- 2. Second order interpolation, where the gain at a certain frequency f is approximated by a 2nd order polynomial passing through three data points fj, fj+1 and fj+2 closest to f.
- 9.1.2.3 Back-off level
- 9.1.2.4 Output power control
- 9.1.3 Receiver inputs (Rx1 & Rx2)
- 9.1.4 External reference oscillator (clk)
- 9.1.5 High level interference
- 9.2 RF control interface
- Figure 9-12: RF control interface, slave and master
- 9.2.1 Tx control signal (B2B_Tx_Ctrl)
- 9.2.2 Rx control signal (B2B_Rx_Ctrl)
- 9.2.3 Tx synchronization signal (B2B_Tx_Sync)
- 1. The rising edge of the signal is referred to as Burst init (tinit). Burst init is meant to be used by activate amplifiers (HPAs) to initialize the gain correctly according to bearer type, EIRP level and frequency range.
- 2. The falling edge of the signal is referred to as Burst start (tstart). Burst start is meant to be used to accurately synchronize the EIRP to a certain level.
- 9.2.4 Tx acknowledge signal (B2B_Tx_Ack)
- 9.2.5 Definition of timing points t0 and t1
- 9.2.6 Timing corrections
- 9.2.7 Burst sequence example
- 9.2.8 SPI interface
- 9.1 RF interface
- Test & diagnostics
- 10.1 Self testing
- 10.2 Continuous monitoring
- 10.3 Fail-safe feature
- 10.4 Error mode
- 1. Internal POST fails.
- 2. If an abnormal behaviour of the modem has been detected which causes the RM to enter fail-safe operation. Fail-safe operation is activated if one of the following circumstances has been detected:
- 3. Detection of internal errors.
- 10.4.1 Protocol error
- 10.4.2 Modem error
- 1. A mandatory configuration is missing during service or waveform activation and the modem cannot proceed to normal operation. In this situation the RM will generate (severity level 5 as described in section 7.7.2 on page 7-33) syslog entries about ...
- 2. Hardware error or internal error captured by the fail-safe feature (see 10.3 on page 10-11)
- 10.5 Diagnostic reporting
- Terminal support
- 11.1 Overview
- 11.2 Software update
- 11.3 Extended POST
- 11.3.1 RF control interface
- 11.3.1.1 Configuration parameter dependent behaviour
- 11.3.1.2 Test procedure
- 1. Start the test by sending the following message on the control interface: MSG_EXT_POST_RF_CONTROL
- 2. The BGAN XL Radio Module will now initiate the test sequence described in section 11.3.1.3 below.
- 3. When the test sequence has ended after approximately 100 ms the BGAN XL Radio Module will return the test results on the control interface in the following message: MSG_EXT_POST_RF_CONTROL_RESP
- 11.3.1.3 Sequence of the RF control interface signals
- 11.3.2 RF Loop-back
- 11.3.3 Bit-Error-Rate testing (BER)
- 11.3.4 TSI Loop-back
- 11.3.1 RF control interface
- 11.4 Drift estimation
- 1. The symbol clock drift of the received forward channel (which is directly related to a misalignment of the reference oscillator) is continuously measured. The clock drift information is available via a set of parameters located in the configuratio...
- 2. The drift of the circuit switched fifo (directly related to the drift in the plesiochronous buffers) is continuously measured.
- 11.4.1 Clock drift
- 11.4.2 CS FIFO drift
- 11.5 Power management
- 1. Save battery power, relevant for battery powered (portable) products.
- 2. To reduce the heat dissipation (all products) in the terminal.
- 11.5.1 SDM sleep
- 11.5.2 Suspend
- 11.5.3 Modem recovery
- Figure 11-8: Modem re-synchronization.
- 1. In scenarios where the satellite signal disappears in a short period of time (up to 400 ms). This mode does not require any interaction from the Integrator as the modem automatically detects signal blocking. When signal blocking is detected the mo...
- 2. If the integrator needs the power consumption to be reduced significantly, as described in the previous section, interaction from the RM is required. In scenarios where the integrator has knowledge that the satellite signal is not available the RM...
- 11.6 AP - BP links
- 11.7 Integrator’s interface
- 11.8 CW transmission
- 11.9 Unframed transmission
- 11.10 BGAN transmission
- 11.11 BGAN reception
- 11.12 Spectrum analyzer
- 11.12.1 Basic operation
- 1. Ensure that the BGAN XL Radio Module is in service mode.
- 2. Access the HTTP based interface on http://192.168.1.1:8080/fft/, in the following referred to as .../fft/ (substitute IP address if non-standard IP configuration is used).
- 3. Configure the parameters for the spectrum and click the “Save All” button. Alternatively, the parameters reflect the ones in the configuration system, so they can also be configured there. See section 6.10.1 on page 6-58 for a full list of con...
- 4. On the web page, click Run Spectrum followed by Refresh Spectrum. A spectrum should appear. For continuous “sweeping” select Continuous. The spectrum will then be renewed approximately once per second, or when a new spectrum is ready, dependin...
- 11.12.2 Measurement principles
- 11.12.3 Measurement considerations
- 11.12.4 Integrator’s interface
- 11.12.5 Python
- 11.12.1 Basic operation
- 11.13 SIM lock
- 11.13.1 Installation of the SIM lock code
- 11.13.2 SIM lock interfaces
- Table 11-18: Return codes from the SIM lock interface
- 1. Each interface has a .result parameter. Before making a request, the client must read this key. If it starts with ‘result=255’, the SIM lock interface is already processing a request, and the client must wait for a few milliseconds and try again.
- 2. When the interface is ready, i.e. the .result parameter does not start with ‘result=255’ anymore, write the configuration parameters (if any) that are needed in the following request.
- 3. Writing the value ‘result=255’ to the .result parameter will trigger a request which will be completed once the .result value is once again different from ‘result=255’.
- 4. When the request has been processed, the result is written back to the .result parameter. The value will always start with the text ‘result=
’, where is one of the numeric codes in Table 11-18 above. - 11.13.2.1 Check SIM lock password
- 11.13.2.2 Get SIM lock penalty time
- 11.13.2.3 Set SIM lock
- 11.13.2.4 Get SIM lock
- 11.13.2.5 Remove SIM lock
- 11.14 Supplementary services (eMLPP registration)
- 11.15 S-Band terminal (FOR INTERNAL USE)
- Use cases
- 12.1 Startup and mandatory configuration
- 12.1.1 Service activation
- 1. Power up the BGAN XL Radio Module
- 2. Read the configuration parameter: 'sys.status.mode'
- 3. Loop step 2 until 'sys.status.mode' is ‘ready’.
- 4. Read the configuration parameters: 'post.status.1' and 'post.status.2' to evaluate the results of the internal connectivity tests. Both parameters must be PASSED as 100% conformity is required. If this is not the case, terminate the activation pro...
- 5. Provide the RM with mandatory configuration via the configuration system.
- 6. Activate service by sending: MSG_WAVEFORM (activate, service).
- 7. Wait for acknowledge via the message: MSG_ACK.
- 12.1.2 Waveform activation (IAI2 mode)
- 1. Load the waveform by sending: MSG_WAVEFORM (load=0, IAI2=0).
- 2. Wait for acknowledge via the message: MSG_ACK.
- 3. Read the configuration parameter: 'sys.status.mode' and verify that the RM is in 'standby' state.
- 4. Provide the RM with additional configuration via the configuration system.
- 5. Activate the waveform by sending: MSG_WAVEFORM (activate=1, IAI2=0).
- 6. Wait for acknowledge via the message: MSG_ACK and verify that 'sys.status.mode' is in 'operating' state.
- 12.1.3 Waveform activation (BPLT mode)
- 1. Load the waveform by sending: MSG_WAVEFORM (load=0, BPLT=1).
- 2. Wait for acknowledge via the message: MSG_ACK.
- 3. Read the configuration parameter: 'sys.status.mode' and verify that the RM is in 'standby' state.
- 4. Provide the RM with additional configuration via the configuration system.
- 5. Activate the waveform by sending: MSG_WAVEFORM (activate=1, BPLT=1).
- 6. Wait for acknowledge via the message: MSG_ACK and verify that 'sys.status.mode' is in 'operating' state.
- 12.1.4 Waveform activation (BPT mode)
- 1. Load the waveform by sending: MSG_WAVEFORM (load=0, BPT=3).
- 2. Wait for acknowledge via the message: MSG_ACK.
- 3. Read the configuration parameter: 'sys.status.mode' and verify that the RM is in 'standby' state.
- 4. Provide the RM with additional configuration via the configuration system.
- 5. Activate the waveform by sending: MSG_WAVEFORM (activate=1, BPT=3).
- 6. Wait for acknowledge via the message: MSG_ACK and verify that 'sys.status.mode' is in 'operating' state.
- 12.1.1 Service activation
- 12.2 Calibration
- 12.2.1 Tx power calibration
- 1. Put the RM into 'service mode' (refer to section 12.1.1).
- 2. Put the antenna into 'cable loss calibration mode'.
- 3. Select the appropriate cable loss calibration algorithm according to class type and antenna type.
- 4. Signal start cable loss calibration to the antenna.
- 5. Set the parameter protocols.bgan.interface.rf.gain.tx.locked to 1 indicating that the parameters are being updated.
- 6. Configure nominal EIRP in the RM via the parameter: protocols.bgan.interface.rf.gain.tx.nominal_power.
- 7. Disable compensation of gain variations in the RM by setting the parameter: protocols.bgan.interface.rf.gain.tx.pwr_pairs to zero.
- 8. Reset protocols.bgan.interface.rf.gain.tx.locked to indicate that the parameters have been updated and are ready to be used.
- 9. Initiate a cable loss calibration algorithm:
- 10. Loop step 9 according to specifications.
- 11. Calculate the cable loss (in dB x100) and verify that it is within the specified range.
- 12. Adjust the nominal EIRP of the RM via the parameter: protocols.bgan.interface.rf.gain.tx.nominal_power, using the information about the calculated cable loss.
- 13. Fetch the antenna configuration parameters (ADU temperature and HPA gain variations) and calculate a combined compensation table (versus frequency).
- 14. Set the parameter protocols.bgan.interface.rf.gain.tx.locked to 1 indicating that the parameters are being updated.
- 15. Configure the RM with the calculated compensation factor via the parameters: protocols.bgan.interface.rf.gain.tx.pwr_freq1..15 and protocols.bgan.interface.rf.gain.tx.pwr1..15.
- 16. Set the parameter: protocols.bgan.interface.rf.gain.tx.pwr_pairs to the needed number of frequency points (1..15).
- 17. Reset protocols.bgan.interface.rf.gain.tx.locked to indicate that the parameters have been updated and are ready to be used.
- 18. Signal cable loss calibration done to the antenna and the RM.
- 12.2.2 Temperature drift
- 12.2.1 Tx power calibration
- 12.3 Network registration
- 12.3.1 Global beam search
- 1. Put the antenna into sky scan mode.
- 2. Allow sky-scan in the BGAN XL Radio Module by sending MSG_BGAN_SKYSCAN_ALLOWED and by sending position data with MSG_NAV_REPORT (see 8.5.4.2 on page 8-33).
- 3. The RM responds by sending MSG_BGAN_SKYSCAN_ALLOWED_RESP. If valid = true then the RM responds by sending MSG_BGAN_START_SKYSCAN with one or more channel numbers of global BGAN signal carriers.
- 4. Initiate the signal validation algorithm in the RM.
- 5. Loop step 4 according to the antenna pointing procedure.
- 6. Terminate when a correct global bearer has been acquired. Alternatively sending MSG_BGAN_SKYSCAN_RESULT indicating that the sky-scan has failed will allow a retry by looping from step 3 with a new MSG_BGAN_START_SKYSCAN.
- 7. Stop sky-scan in the BGAN XL Radio Module by sending: MSG_BGAN_SKYSCAN_RESULT indicating that the sky-scan has succeeded.
- 8. Signal sky-scan mode done to the antenna.
- 12.3.2 Registration
- 1. Notify the BGAN XL Radio Module that a USIM card is available by setting the configuration parameter platform.usim.status to 1. The RM now uses the protocol specified in section 8.5.2.11 on page 8-29 to access the USIM card.
- 2. Provide the RM with a valid GPS position for the current location. This is done by sending MSG_NAV_REPORT to the RM.
- 3. Wait for response from the RM:
- 4. The RM will now automatically initiate the network registration procedure for CS services.
- 5. The status of this procedure may be monitored by reading the configuration parameter protocols.umts.cs.status:
- 12.3.1 Global beam search
- 12.4 Connection setup
- 12.5 Operation
- 12.5.1 ATC handling
- 1. Provide the RM with mandatory and additional configuration as described in section 12.1.1 and 12.1.2.
- 2. Activate the RM to operate in 'bgan_waveform mode'.
- 3. Before the sky-scan procedure is activated ensure that the RM is configured to operate in the ATC active mode either by enabling the external ATC filter or via the parameter: protocols.bgan.functionality.atc.activation = 1.
- 4. Now sky-scan can be activated and pointing be performed.
- 5. After completion of the pointing procedure (and during operating) a surveillance algorithm that monitors the external ATC detector must be activated.
- 6. Loop step 5 continuously.
- 12.5.1 ATC handling
- 12.6 Services
- 12.6.1 Spectrum analyzer (spectrum measurement)
- 1. First ensure that no other service-related functions are active.
- 2. Set the span to 2 MHz, the centre frequency to 1550 MHz, the number of averages to 100, the window type to Hanning and the gain to -1.00 dB by filling the appropriate boxes at http://192.168.1.1:8080/fft/ and clicking Save All
- 3. Instruct the spectrum analyzer to perform the FFT/measurements by clicking Run Spectrum followed by Refresh Spectrum
- 4. Now the measured spectrum can be visually inspected
- 5. You can find additional measurements at http://192.168.1.1:8080/fft/fft_data, which contains information similar to:
- 12.6.2 Spectrum analyzer (spurious search)
- 1. First ensure that no other service related functions are active.
- 2. Set the span to 2 MHz, the number of averages to 100, the window type to Hanning, the centre frequency to 1550 MHz and the gain to -1.00 dB by accessing http://192.168.1.1:8080/intif/fftsa/config?span=2000&avg=100&win=hanning&freq=1 550000000&gain...
- 3. The spurious are relatively far away from the applied signal, so the spurious (removal) bandwidth is set to 50 kHz by accessing http://192.168.1.1:8080/intif/fftsa/config?spur=50000
- 4. Instruct the spectrum analyzer to perform the FFT/measurements by accessing http://192.168.1.1:8080/intif/fftsa/makefft
- 5. Verify that the spectrum analyzer is in the idle state and thus the measurements are done, by accessing http://192.168.1.1:8080/intif/status
- 6. Now the measured spectrum can be visually inspected by accessing http://192.168.1.1:8080/fft/ and clicking Refresh Spectrum
- 7. The spur measurements can be found at http://192.168.1.1:8080/fft/fft_data, which contains information similar to (note the spur1..spur4 values):
- 12.6.3 Spectrum analyzer (phase noise measurement)
- 1. First ensure that no other service related functions are active.
- 2. Set the span to 2 MHz, the number of averages to 100, the window type to Hanning, the centre frequency to 1550 MHz, the gain to -1.00 dB and the spurious (removal) bandwidth to 50 kHz by accessing http://192.168.1.1:8080/intif/fftsa/config?span=20...
- 3. Set the phase noise offset to -300 kHz and the phase noise bandwidth to 2 kHz by accessing http://192.168.1.1:8080/intif/fftsa/config?pno=-300000&pnbw=2000
- 4. Instruct the spectrum analyzer to perform the FFT/measurements by accessing http://192.168.1.1:8080/intif/fftsa/makefft
- 5. Verify that the spectrum analyzer is in the idle state and thus the measurements are done, by accessing http://192.168.1.1:8080/intif/status
- 6. Find the phase noise measurements at http://192.168.1.1:8080/fft/fft_data, which contains information similar to (note the phase_noise value):
- 7. As the phase noise offset is relative to frequency (peak_freq) the phase noise offset must be set to -248 kHz by accessing http://192.168.1.1:8080/intif/fftsa/config?pno=- 248000
- 8. Note that for the best dynamic range for phase noise measurement, the channel power (full scale) should be in the range -10 to -4 dBFS. This can be achieved by changing the gain to 20 dB by accessing http://192.168.1.1:8080/intif/fftsa/config?gain=20
- 9. Instruct the spectrum analyzer to perform the FFT/measurements by accessing http://192.168.1.1:8080/intif/fftsa/makefft
- 10. Verify that the spectrum analyzer is in the idle state and thus the measurements are done, by accessing http://192.168.1.1:8080/intif/status
- 11. Find the phase noise measurements at http://192.168.1.1:8080/fft/fft_data, which contains information similar to (note the significantly higher phase_noise value):
- 12.6.4 Changing satellite table
- 1. Put the RM into 'waveform mode' (refer to section 12.1.2).
- 2. Set the parameter protocols.bgan.functionality.satellite_table.change.locked to 1 indicating that the parameters are being updated.
- 3. Set the parameter protocols.bgan.functionality.satellite_table.change.satellite_id to the same ID used in the satellite table entry that should be changed.
- 4. Set the parameters protocols.bgan.functionality.satellite_table.change.position, protocols.bgan.functionality.satellite_table.change.channel.primary and protocols.bgan.functionality.satellite_table.change.channel.alternate to the new values.
- 5. Set protocols.bgan.functionality.satellite_table.change.default to 0.
- 6. Reset protocols.bgan.functionality.satellite_table.change.locked to indicate that the parameters have been updated and are ready to be used.
- 7. The RM will now read the changed values and update the satellite table. The satellite table will only be update if the .satellite_id set in step 3 already exists.
- 12.6.5 Reset satellite table to default
- 1. Put the RM into 'waveform mode' (refer to section 12.1.2).
- 2. Set the parameter protocols.bgan.functionality.satellite_table.change.locked to 1 indicating that the parameters are being updated.
- 3. Set protocols.bgan.functionality.satellite_table.change.default to 1.
- 4. It is not necessary to set any of the other protocols.bgan.functionality.satellite_table.change parameters.
- 5. Reset protocols.bgan.functionality.satellite_table.change.locked to indicate that the parameters have been updated and are ready to be used.
- 6. The RM will now reset the satellite table.
- 12.6.1 Spectrum analyzer (spectrum measurement)
- 12.7 Physical & protocol layer test
- 12.7.1 BPLT testing
- 1. Connect the user terminal to the RF unit of the BPLT.
- 2. A network cable interconnecting the BPLT with the user terminal.
- 12.7.1.1 Doppler correction in BPLT Waveform
- Table 12-2: Doppler compensation execution as result of Doppler compensation source data input to the RM
- 1. Restart of the RM (Doppler correction mode is enabled).
- 2. First satellite longitude is received.
- 3. First position is received.
- 4. Configure LESP Bearer received but not executed since velocity is required until Doppler compensation can be calculated.
- 5. First velocity message is received, Doppler compensation can now be calculated and the stored Configure LESP Bearer message is handled.
- 6. New satellite longitude received.
- 7. New velocity message received.
- 12.7.1.2 BPLT Test setup NF calibration guideline
- Figure 12-2: Noise figure calibration
- 1. Verify the attenuator setting in bplt.ini
- 2. Boot UT Radio Module into service mode, See 12.1.1 on page 12-2
- 3. Measure and log the temperature of the test: ]
- 4. Manually setup a CW on the BPLT and log the Tx Level from Bearer status window at 1542 MHz:
- 5. Calculate the UT input level:
- 6. Run the spectrum analyzer (see 12.6.1 on page 12-11) with the following parameters set
- 7. Log the CW Level found by the Spectrum analyzer (
). See 12.6.1 on page 12-11: - 8. Calculate the UT LNA gain between UT input and RM input:
- 9. Tear down the CW on the BPLT completely in bearer and channel control.
- 10. Run the spectrum analyzer with the following parameters set
- 11. Log the Noise Level found by the Spectrum analyzer (
): - 12. Calculate the Thermal Noise given a perfect receiver:
- 13. Calculate the Noise Figure:
- 14. Repeat Steps 3-13 for all relevant temperatures and frequencies.
- 15. Boot UT Radio Module into BPLT mode to perform MTR tests
- 12.7.2 BPT testing
- 1. BPLT (BGAN Physical Layer Tester)
- 2. BPT (BGAN Protocol Tester, a PC running the Test Case Manager application)
- 3. User terminal under test
- 4. All necessary cables (see figure below)
- 12.7.2.1 Test setup
- Figure 12-3: Physical and protocol layer test, setup
- 1. The latest version of the test suites has been obtained from Inmarsat and installed.
- 2. Appropriate changes to the test parameters have been made to accommodate for the particular configuration of the User Terminal under test.
- 3. The latest release of the BPT and BPLT have been installed and configured.
- 12.7.2.2 Configuring the BGAN XL Radio Module for protocol testing
- 1. Load and activate an IAI2 waveform (see section 12.1.2 on page 12-2).
- 2. Execute the initial Python script in order to set values needed for protocol testing inside the RM.
- 3. Execute the appropriate Python script, depending on which MTR script(s) must be executed. As a rule of thumb, one Python file corresponds to a test suite, however it is worth noting that some MTR scripts require a slightly different configuration ...
- 4. Make sure the variables in the pixit files (.tsp files supplied by Inmarsat along with the MTR scripts) contains the correct values in accordance with the User Terminal under test. The following values must be set correctly (the parentheses indica...
- 5. There must be a special protocol test (dummy) SIM card in the user terminal. The px_AuthK and px_ck field in the pixit files must be adjusted to correspond with the value on the SIM card.
- 12.7.3 VCTS testing
- Figure 12-4: VCTS test setup
- 1. Connect the test equipment as pictured above.
- 2. Run the Python script VCTS_end_to_end.py that sets the terminal up for VCTS testing.
- 3. Set up the VCDS for a new test.
- 4. Run the script VCTS_end_to_end.rls in Test Case Manager.
- 5. When the CS connection has been established make all end-to-end tests in the VCDS software.
- 12.7.1 BPLT testing
- 12.1 Startup and mandatory configuration
- Applications
- Type approval
- 14.1 Introduction
- 14.2 Pre-approved MTRs
- 14.3 Physical layer
- Figure 14-3: BPLT test setup
- 14.3.1 MTR 6 Receiver Tuning Range
- 14.3.2 MTR 7 QPSK frame acquisition
- 14.3.3 MTR 8 QPSK packet error rate
- 14.3.4 MTR 9 QAM Frame Acquisition
- 14.3.5 MTR 10 QAM Packet Error Rate
- 14.3.6 MTR 11 QPSK selectivity
- 14.3.7 MTR 12 QAM selectivity
- 14.3.8 MTR 13 Receiver dynamic range
- 14.3.9 MTR 14 EIRP Determination and Stability
- 14.3.10 MTR 15 Transmitter Off Level
- 14.3.11 MTR 16 Spurious and Harmonics
- 14.3.12 MTR 17 Transmitter Phase Noise
- 14.3.13 MTR 18 Transmitter Tuning Performance
- 14.3.14 MTR 19 Transmitter Frequency Accuracy and Stability
- 14.3.15 MTR 20 Modulator Performance
- 14.3.16 MTR 21 Transmit Burst Characteristics
- 14.3.17 MTR 23 C/No Measurement and Reporting
- 14.3.18 MTR 24 Transmitter Coding Performance
- 14.3.19 MTR 25 Transmitter Burst Timing Accuracy and Stability
- 14.3.20 MTR 26 Transmitter Power Spectral Density
- 14.3.21 MTR 28 Code Rate Detection
- 14.3.22 MTR 31 Dynamic Modulation
- 14.4 Protocol layer
- References
- A.1 Applicable standards and RFC
- [1] 3GPP TS 27.007 V4.7.0 (2010-03), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; AT command set for User Equipment (UE) (Release 4)
- [2] 3GPP TS 27.005 V4.2.1 (2005-01), 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE - DCE) interface for Short Message Service (SM...
- [3] Request for Comments: 2617, June 1999, HTTP Authentication: Basic and Digest Access Authentication
- [4] Request for Comments: 4412, February 2006, Communications Resource Priority for the Session Initiation Protocol (SIP)
- [5] Request for Comments: 3261, June 2002, SIP, Session Initiation Protocol
- [6] Request for Comments: 3326, December 2002, The Reason Header Field for the Session Initiation Protocol (SIP)
- [7] Request for Comments: 3323, November 2002, A Privacy Mechanism for the Session Initiation Protocol (SIP)
- [8] Request for Comments: 3551, July 2003, RTP Profile for Audio and Video Conferences with Minimal Control
- [9] Request for Comments: 4040, April 2005, RTP Payload Format for a 64 kbit/s Transparent Call
- [10] Request for Comments: 5424, March 2009, The Syslog Protocol
- [11] Request for Comments: 5426, March 2009, Transmission of Syslog Messages over UDP
- [12] Request For Comments: 1350, July 1992, THE TFTP PROTOCOL (REVISION 2)
- [13] Request for Comments: 2616, June 1999, Hypertext Transfer Protocol -- HTTP/1.1
- [14] Request for Comments: 3550, July 2003, RTP: A Transport Protocol for Real-Time Applications
- [15] Request for Comments: 854, May 1983, TELNET PROTOCOL SPECIFICATION
- [16] Universal Serial Bus Specification, revision 2.0 (also referred to as the USB Specification)
- [17] On-The-Go Supplement to the USB 2.0 Specification, Revision 1.0, Dec 18, 2001
- [18] [SDM] BGAN System Definition Manual, Release 4.8.0 (2016-02), Inmarsat
- [19] Request for Comments: 2516, February 1999, A Method for Transmitting PPP over Ethernet (PPPoE)
- [20] Request for Comments: 4938, February 2010, PPPoE Extensions for Credit Flow and Link Metrics.
- [21] 3GPP TS 31.102 V4.15.0 (2005-06), 3rd Generation Partnership Project; Technical Specification Group Terminals; Characteristics of the USIM Applications (Release 4)
- [22] 3GPP TS 27.010 V4.2.0 (2002-03), 3rd Generation Partnership Project; Technical Specification Group Terminals; Terminal Equipment to User Equipment (TE-UT) multiplexer protocol (Release 4)
- A.1 Applicable standards and RFC
- Glossary
Management services
99-137719-D Confidential - For internal use 7-33
7777
Data interfaces
7.7.2 Syslog interface
The BGAN XL Radio Module supports a subset of the syslog protocol described in RFC
5424 [10] and RFC 5426 [11] and operates as a syslog originator whereas the application
processor operates as a syslog collector or relay. As allowed in the RFC, the RM will
use its IP address in the HOSTNAME field of the syslog protocol.
As a syslog originator the RM will transmit events originating from either internal (the
protocol processor or the modem) or external sources submitted via the control
interface (see section 8.5.2.6 on page 8-19). Internal events use RM as the APP-NAME
whereas external sources will have to use another unique APP-NAME. All generated
entries will get a timestamp at the time it is issued from the RM. The timestamp will
contain the system time of the RM in UTC time, if known. If the RM does not have time
information from a GPS fix, the time since boot of the RM will be used (a time in 1970).
The application processor may operate as a syslog relay, relaying syslog entries to an
application on an external unit, or as a syslog collector, storing the syslog entries in
RAM or flash locally.
All syslog entries will be tagged with the local0 message facility. Each entry is assigned
a message severity by the issuer on the scale shown in the following table:
Figure 7-4: Notification sequence with multiple parameters
Value Severity
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
Table 7-26: Syslog entries — severity levels