## org.freedesktop.ModemManager1.Modem.Modem3gpp.ProfileManager org.freedesktop.ModemManager1.Modem.Modem3gpp.ProfileManager — The ModemManager 3GPP profile management interface. |

## Methods

    List   (OUT aa{sv} profiles);
    Set    (IN  a{sv}  requested_properties,
            OUT a{sv}  stored_properties);
    Delete (IN  a{sv}  properties);

## Signals

    Updated ();

## Properties

    IndexField  readable   s

## Description

This interface provides access to actions with connection profiles.

This interface will only be available once the modem is ready to be registered in the cellular network. 3GPP devices will require a valid unlocked SIM card before any of the features in the interface can be used.

The user of the interface can optionally choose to use the new profile management methods to manage the connection setup, e.g by using the new `"profile-id"` setting in either the CreateBearer or the Connect methods. If that's the case, it is suggested that the legacy approach of not using the profiles is completely avoided. If both approaches are used at the same time, it may happen that a connection attempt not using the `"profile-id"` implicitly updates a given profile (without emitting Updated), as the amount of profiles implemented in modems may be fixed.

## Method Details

### The `List()` method

    List (OUT aa{sv} profiles);

Lists the available profiles or contexts provisioned on the modem.

Profiles are represented as dictionaries of properties, and any of the 3GPP-specific properties defined in the bearer properties are allowed.

Depending on the implementation, the settings applicable to the initial EPS bearer given in bearer properties may also be reported as an item in the returned list, identified by the `MM_BEARER_APN_TYPE_INITIAL` `"apn-type"` flag.

Since: 1.18

`OUT aa{sv} `profiles``: | An array of dictionaries containing the properties of the provisioned profiles.

### The `Set()` method

    Set (IN  a{sv} requested_properties,
         OUT a{sv} stored_properties);

Creates or updates a connection profile on this modem, depending on whether the expected index field is given or not. If not given, a new profile will be created; otherwise, the profile with the given index will be updated.

Profiles are represented as dictionaries of properties, and any of the 3GPP-specific properties defined in the bearer properties are allowed. The real list of supported properties really depends on the underlying protocol and implementation, though; e.g. in AT-based modems setting `"apn-type"` won't be supported, and instead the user should give that setting explicitly when creating the bearer object.

The operation may fail if it is attempting to update an existing profile for which connected bearer objects already exist. In this case, the user should make sure these bearer objects are already disconnected before attempting to change the profile settings.

The operation may also fail if it is attempting to update the profile associated to the settings of the initial EPS bearer, identified by the `MM_BEARER_APN_TYPE_INITIAL` `"apn-type"` flag. In this case, `SetInitialEpsBearerSettings()` should be used instead.

The output `stored_properties` will contain the settings that were successfully stored, including the new `"profile-id"` if the operation was creating a new profile.

Since: 1.18

`IN a{sv} `requested_properties``: | the requested profile properties.
`OUT a{sv} `stored_properties``: | the stored profile properties.

### The `Delete()` method

    Delete (IN  a{sv} properties);

Deletes the profile with the index field given in `properties`.

If additional settings are given in `properties` they are ignored. This allows the user to easily request the deletion of a profile that has been provided in the `List()` operation.

This method may just clear the existing profiles (i.e. resetting all the properties to defaults) instead of fully removing them if the profiles cannot be fully removed. In this case, the method will succeed, but the size of the list of profiles will not change.

This method will fail if the expected index field is not given.

The operation may fail if it is attempting to delete a profile for which connected bearer objects already exist. In this case, the user should make sure these bearer objects are already disconnected before attempting to delete the profile.

The operation may also fail if it is attempting to delete the profile associated to the settings of the initial EPS bearer, identified by the `MM_BEARER_APN_TYPE_INITIAL` `"apn-type"` flag. In this case, `SetInitialEpsBearerSettings()` may be used instead to clear these settings.

Since: 1.18

`IN a{sv} `properties``: | the profile properties.

## Signal Details

### The "Updated" signal

    Updated ();

Emitted when the profiles are updated by the network through OTA procedures.

This signal should not be emitted due to operations performed through this interface, e.g. with a `Set()` call. The logic implementing this support has certain limitations, so it is suggested to reload the full list of profiles with a new `List()` call and check for differences as needed.

The emission of this signal may also not be fully reliable, if for example the support for this type of notifications is not provided by the modem itself, or if the modem report for an OTA update happens too close to one of our own operations.

Since: 1.18

## Property Details

### The "IndexField" property

    IndexField  readable   s

Indicates which field should be considered as unique index, depending on the underlying protocol.

This will be 'profile-id' by default for all implementations, and only set to 'apn-type' for MBIM devices implementing the Microsoft profile management interface extensions.

Since: 1.20