Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add semantic convention for describing network connectivity conditions #1647

Open
bryce-b opened this issue Apr 26, 2021 · 4 comments
Open
Labels
area:semantic-conventions Related to semantic conventions spec:trace Related to the specification/trace directory

Comments

@bryce-b
Copy link
Member

bryce-b commented Apr 26, 2021

What are you trying to achieve?
On mobile devices, the state of network connectivity is very important. Determining the severity of a network issue can be greatly impacted by the networking state a mobile device is operating under. These values would only be useful applied to network transactions.

I would like to add several semantic conventions to the spec to describe network conditions on a mobile device. To get the conversation started here a some proposed attributes:

network.effectiveType
This can describe whether the device is connected via wifi, 2G, 3G, 4G, 5G.

network.carrier
Describes the cellular carrier if applicable. e.g. : Sprint

network.isoCode
2 character country code per ISO 3166-1 standard. e.g.: DE for Germany

network.mobileCode
The mobile network code (MNC) of a cell service provider. e.g.: 050
Though this is a numeric code, it's probably wise to transmit as a string to preserve leading zeros.

network.countryCode
The mobile country code (MCC). e.g.: 312
This may also have leading zeros and should be transmitted as a string.

The MCC & MNC can be used to uniquely identify a mobile network operator. All three codes are valuable, as one particular MCC may service multiple countries.

For more information on these values : https://en.wikipedia.org/wiki/Mobile_country_code

@bryce-b bryce-b added the spec:trace Related to the specification/trace directory label Apr 26, 2021
@Oberon00 Oberon00 added the area:semantic-conventions Related to semantic conventions label Apr 27, 2021
@Oberon00
Copy link
Member

Oberon00 commented Apr 27, 2021

These seem potentially useful to me.

I think you are already suggesting that but just to add a rationale: Adding these per span would make sense as a device may have multiple connections. Also, resources being immutable or maybe soon append-only (#1298 (comment)) may not really fit that.

A few notes on the names in general:

  1. We have a general naming guide at https://github.com/open-telemetry/opentelemetry-specification/blob/v1.2.0/specification/common/attribute-and-label-naming.md which mandates the use of snake_case, so you would use network.effective_type, etc. instead of network.effectiveType.
  2. We already have namespaces net, net.peer and net.host, see https://github.com/open-telemetry/opentelemetry-specification/blob/v1.2.0/specification/trace/semantic_conventions/span-general.md#general-network-connection-attributes. I believe these attributes would best be put under net.host or maybe net.host.mobile / net.host.cellular.

And on particular names:

  1. effectiveType: Why "effective"?
  2. isoCode: That's too generic IMHO. Maybe iso_country_code
  3. mobileCode, countryCode: if MNC/MCC are well-known enough, I would go for using these, or their expanded equivalents (for example mobile_network_code instead of just mobileCode). Especially countryCode is confusing together with isoCode.

The MCC & MNC can be used to uniquely identify a mobile network operator. All three codes are valuable, as one particular MCC may service multiple countries.

In that case maybe use *carrier.mcc, *carrier.mnc, *carrier.name as attributes?

@bryce-b
Copy link
Member Author

bryce-b commented Apr 28, 2021

effectiveType: Why "effective"?

The radio access technology name is rather esoteric, e.g.WCDMA, HSUPA, CDMAx1, etc. Categorizing them into more user friendly names is where the idea of "effective_type" comes from, e.g. 1G, 2G, 3G, etc.

@bryce-b
Copy link
Member Author

bryce-b commented Apr 28, 2021

  1. isoCode: That's too generic IMHO. Maybe iso_country_code

maybe icc? If we decide mcc & mnc are ok.

I like *carrier.mcc, *carrier.mnc, *carrier.name.

I'll defer to the experts on namespace, net.host might be a good place.

I forgot to mention one additional caveat with effective_type it may also be wifi, under which case all the other information would probably be moot.

@bryce-b
Copy link
Member Author

bryce-b commented Apr 30, 2021

how about the following?
net.host.connection_type: 5G,4G,3G,2G,1G, wifi,unavailable (String)
net.host.carrier.mcc : mobile country codes (String)
net.host.carrier.mnc : mobile network codes (String)
net.host.carrier.name: Carrier names (String) (e.g.: T-Mobile, AT&T, etc)
net.host.carrier.icc: 2-character iso country code (String) (e.g.: US, DE)

bryce-b added a commit to bryce-b/opentelemetry-specification that referenced this issue May 4, 2021
bryce-b added a commit to bryce-b/opentelemetry-specification that referenced this issue May 4, 2021
bryce-b added a commit to bryce-b/opentelemetry-specification that referenced this issue Jun 10, 2021
jmacd pushed a commit that referenced this issue Jul 12, 2021
* added spec changes per #1647

* added 'wired' as possible value to `net.host.connection_type`

* fixed spacing in CHANGELOG.md

* added mobile carrier attributes to  semantic_conventions/trace/general.yaml

* fixed issue revealed by

* reverted extra space per markdownlint

* made connection_type allow custom values

* added additional space

* removed manually added table & ran generator tool

* separated connection.type & connection.subtype

* updated changelog to reflect iteration

* added literal radio tech to connection.subtype table

* added  as option for connect.type

Co-authored-by: Armin Ruech <[email protected]>
Co-authored-by: Carlos Alberto Cortez <[email protected]>
carlosalberto added a commit to carlosalberto/opentelemetry-specification that referenced this issue Oct 31, 2024
* added spec changes per open-telemetry#1647

* added 'wired' as possible value to `net.host.connection_type`

* fixed spacing in CHANGELOG.md

* added mobile carrier attributes to  semantic_conventions/trace/general.yaml

* fixed issue revealed by

* reverted extra space per markdownlint

* made connection_type allow custom values

* added additional space

* removed manually added table & ran generator tool

* separated connection.type & connection.subtype

* updated changelog to reflect iteration

* added literal radio tech to connection.subtype table

* added  as option for connect.type

Co-authored-by: Armin Ruech <[email protected]>
Co-authored-by: Carlos Alberto Cortez <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions spec:trace Related to the specification/trace directory
Projects
None yet
Development

No branches or pull requests

2 participants