| Age | Commit message (Collapse) | Author |
|---|
|
adding bandwidth information in mm-dbus interface
for the serving cell. In serving cell, the details
on whether the pcell/scell are from MCS or SCG is
also updated.
Co-author: Shilpa Shivakumar
|
|
According to 3GPP Rel16.3, 38104, band NGRAN-53 is supported.
Band info as below:
n53 2483.5 MHz - 2495 MHz, TDD
Signed-off-by: Slark Xiao <slark_xiao@163.com>
|
|
|
|
|
|
|
|
LTE Band 85 is supported by modems based on Qualcomm 9205 chipset.
|
|
Instead of not creating a modem object, create it in failed state with
the "unknown capabilities" failed state reason.
|
|
A modem using an eSIM without profiles should not be allowed to get
enabled, it should be really treated as a modem without a physical
SIM.
|
|
The rights each contributor has are the ones stated by the GPL/LGPL,
not more and not less.
|
|
|
|
This new method allows querying the modem for information about the
current serving cell(s) as well as any other neighboring cell that may
be found.
The information for the cells is given in an array of dictionaries,
where each element of the dictionary is a new dictionary itself.
Each cell type has a different set of properties that may be given in
the dictionary, and some of those properties in each type are also
applicable under certain conditions (e.g. only applicable to the cell
if it's a 'serving' cell instead of 'neighboring').
The API documentation explains in detail what is expected in each
case.
|
|
Sometimes it's useful to know how a given stored profile was created,
so devices can store and report this kind of information.
|
|
The 'allow-roaming' setting should be considered deprecated for 3GPP
devices that support the new 'roaming-allowance' setting, which is
much more detailed (as it allows to differentiate between partner and
non-partner networks) and may also be stored as part of a profile.
|
|
In 5G capable devices, which can support multiple types of access
types (either 3GPP or non-3GPP), the UE may request to use a 3GPP
access type exclusively, prefer a 3GPP access type, or just report no
preference.
When supported, this field may also be part of the settings that can
be stored as part of a profile.
|
|
|
|
A new set of property+method is added to be able to configure the 5G
specific registration settings, initially defining the support for the
MICO mode.
The property name starts with "Nr5g" instead of "5gNr" because of the
limitations imposed by the GObject type system on how properties with
numbers can be named.
|
|
|
|
|
|
|
|
|
|
Mostly based on the Microsoft extensions for MBIM. They'll need to be
mapped to other protocols (e.g. QMI) somehow.
|
|
This property allows the user to know whether the device is attached
or detached from the packet domain service.
|
|
|
|
|
|
This reverts commit 6ffe84a122b9a79a8f0951af5ee5075f16726bdd.
|
|
(cherry picked from commit 2cb38c568ff1fb26b23bad5e8a2851547448c30e)
|
|
Based on the QDU service newly added in libmbim,
T99W175 module (vid: 0x105b) supports MBIM QDU based update.
|
|
This new setting allows the user setting up the connection to specify
the purpose of the connection being brought up.
Until now, we would always assume that connections are exclusively
brought up for connecting to the Internet, also limited by the
inability to connect to multiple different APNs at the same time.
But that may really not be true as there may be additional services
that may be accessed through other APNs, like MMS services or even
private networks for companies that have their own APNs on a given
operator (e.g. not that uncommon with banks and connected cars).
The new APN type setting will not change the way the bearer is
connected, but will allow the connection manager to decide what kind
of networking setup the specific connection needs.
This new setting can be provided by the user itself, or implicitly
read from the device if the device stores this information.
|
|
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
|
|
At the moment, ignored ports show up as (unknown) in the ports list
in mmcli. This makes it look like something went wrong while probing.
Actually ModemManager already tracks unknown and ignored ports separately
(MM_PORT_TYPE_UNKNOWN vs MM_PORT_TYPE_IGNORED) but the API always exposes
them as MM_MODEM_PORT_TYPE_UNKNOWN.
Add MM_MODEM_PORT_TYPE_IGNORED and use this for ignored ports so they
show up as (ignored) instead in mmcli.
|
|
Reporting the state when the UE attaches to access restricted local
operator services.
|
|
|
|
|
|
|
|
It's not used anywhere.
|
|
|
|
Instead of flagging them as 'ignored' so that they aren't probed, we
can also flag them as 'audio' now, so that the logic knows which port
to report as used for audio in the Call object.
|
|
So that we can avoid gtk-doc complaining about them:
2019-10-14 10:46:59,583:common.py:ParseEnumDeclaration:427:WARNING:Cannot parse enumeration member:
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_FIRST is missing in source code comment block.
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_LAST is missing in source code comment block.
|
|
This method allows deflecting an incoming or waiting call to a
different number.
|
|
This method will join all active and held calls into a single
multiparty call, and then request the network to terminate the call on
the subscriber's end and transfer the control of the call to the
parties that are still in the call.
|
|
|
|
|
|
|
|
Much clearer to understand when looping through them.
|
|
The A-GPS based implementations we currently have assume MSA A-GPS, so
rename the MMModemLocationSource enum value to reflect that.
|
|
|
|
Devices may require/support more than one update method, so instead of
reporting the method as a single enum value, use a set of flags
instead.
|
|
|
|
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
|
|
|
