2. Content
• Changes in trace due to 5g traffic control guidelines
• Why trace-changes in the UE domain
• Changed trace points
• Changed log levels
• Recommended streaming configuration
• General tracing information
• Snapshot based traces
• Lttng session overview
• Lttng log levels
• Usage
• Streaming based traces
• Overview
• Usage
• References
3. Why trace changes in the UE domain
• Work ongoing to align tracing according to 5G traffic control trace
guidelines
• Changed log level of existing trace points
4. Changed trace points
• DEBUG_MSG_SENT/REC
• Replaced with specific trace points
• OBS_MSG, COLI_MSG,CONFIG_MSG,UE_INFO_MSG
• Service state traces
• Previously we only used CONNECT once connection succeeded
• CONNECT – should be interpreted as an "attempt"
• CONNECT_SUCCESS
• CONNECT_FAILURE
• UE-dedicated versions of ABNORMAL and ERROR that accepts a UE-trace
context as argument
• ABNORMAL_UE
• ERROR_UE
• Added a few new fields to the service-related traces
5. Changed log levels
• XXX_ENCODE/DECODE
• Previously mapped on TRACE_INFO
• Now mapped on TRACE_DEBUG_SYSTEM
• Still enabled by default, moved from long term buffer to short term buffer
• NOTE: This means that they are no longer active by default when streaming traces
• PROC_START/FAILURE
• Previously mapped on TRACE_INFO
• Now mapped on TRACE_DEBUG_SYSTEM
• Still enabled by default, moved from long term buffer to short term buffer
• NOTE: This means that they are no longer active by default when streaming traces
6. Recommended streaming configuration
• To get XXX_ENCODE/DECODE:
ts e 1 F1AP_ENCODE *
ts e 1 F1AP_DECODE *
ts e 1 E1AP_ENCODE *
ts e 1 E1AP_DECODE *
ts e 1 RRC_ENCODE *
ts e 1 RRC_DECODE *
ts e 1 NGAP_ENCODE *
ts e 1 NGAP_DECODE *
ts e 1 X2AP_ENCODE *
ts e 1 X2AP_DECODE *
ts e 1 XNAP_ENCODE *
ts e 1 XNAP_DECODE *
ts e 1 NRPPA_ENCODE *
ts e 1 NRPPA_DECODE *
ts e 1 S1AP_ENCODE *
ts e 1 S1AP_DECODE *
7. General tracing information 1/2
• Documentation of UE-trace points:
• https://developer.internal.ericsson.com/docs/traffic-
control/components/ue/architecture/trace/overview/
8. General tracing information 2/2
• Snapshot-based traces
• Controlled by the te-command
• Streaming-based traces
• Controlled by the ts-command
• Different mechanisms with different "always-on"-behavior
9. Snapshot based traces - Lttng
session overview
• Two separate sessions
• Long-term and short-term
• Long-term size = 4x short-term size
11. Snapshot based traces - usage
• te log read
• Takes a snapshot of both the long-term and the short-term channels
• Can also be used to only operate on one of the channels:
• te log read [session|-short|-long] All sessions are read if the session name is omitted
• te log read –l
• Also includes the log-level of a trace point in the log
• te log clear
• Clears lttng sessions
• Can also be used to only operate on one of the sessions:
• te log clear [-short|-long] All sessions are cleared if no option provided
12. Snapshot based traces - usage
• te enable
• Enables lttng events for the long-term channel
• Example:
• te enable event1 event2 com_ericsson_my_provider
• te enable * com_ericsson_my_provider
• NOTE: Only operates on the long-term channel
• te default off <t>
• Disables default traces for <t> hours, default 1h
• NOTE: Only operates on the long-term channel
• 'te' without any arguments shows help
13. Streaming based traces - overview
• Different mechanism compared to snapshot-based tracing
• Controlled by 'ts'-command
• 'te'-command does not affect streamed sessions
• Different always-on behavior compared to snapshot based
14. Streaming based traces - usage
• Streamed sessions are created with the 'mon'-moshell command
• To inspect the traces enabled, use ts status
• By default, the same settings as for the long-term
snapshot session will used:
* (loglevel <= TRACE_INFO)
15. Streaming based traces - usage
• 'ts enable' to enable more traces
• ts e 1 * com_ericsson_rc_ue_nr_ue