Connectivityinsights
ConnectivityinsightsSubscriptions
Connectivity Insights Subscriptions
Create a Connectivity insights subscription for a device
Retrieve a list of apiName event subscription
Operation to retrieve a subscription based on the provided ID
Operation to delete a subscription
ModelsExpand Collapse
Config object { subscriptionDetail, initialEvent, subscriptionExpireTime, subscriptionMaxEvents } Implementation-specific configuration parameters needed by the
subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime,
subscriptionMaxEvents, initialEvent
Specific event type attributes must be defined in subscriptionDetail
Note: if a request is performed for several event type, all subscribed
event will use same config parameters.
Implementation-specific configuration parameters needed by the
subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime,
subscriptionMaxEvents, initialEvent
Specific event type attributes must be defined in subscriptionDetail
Note: if a request is performed for several event type, all subscribed
event will use same config parameters.
subscriptionDetail: object { applicationProfileId, device, applicationServer, applicationServerPorts } The detail of the requested event subscription
The detail of the requested event subscription
device: object { ipv4Address, ipv6Address, networkAccessIdentifier, phoneNumber } End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators.
The developer can choose to provide the below specified device identifiers:
* ipv4Address
* ipv6Address
* phoneNumber
* networkAccessIdentifier
NOTE1: the network operator might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different network operators. In this case the identifiers MUST belong to the same device.
NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators.
The developer can choose to provide the below specified device identifiers:
* ipv4Address
* ipv6Address
* phoneNumber
* networkAccessIdentifier
NOTE1: the network operator might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different network operators. In this case the identifiers MUST belong to the same device.
NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
ipv4Address: optional object { privateAddress, publicAddress, publicPort } The device should be identified by either the public (observed) IP
address and port as seen by the application server, or the private
(local) and any public (observed) IP addresses in use by the device
(this information can be obtained by various means, for example from
some DNS servers).
If the allocated and observed IP addresses are the same (i.e. NAT is
not in use) then the same address should be specified for both
publicAddress and privateAddress.
If NAT64 is in use, the device should be identified by its
publicAddress and publicPort, or separately by its allocated IPv6
address (field ipv6Address of the Device object)
In all cases, publicAddress must be specified, along with at least one
of either privateAddress or publicPort, dependent upon which is known.
In general, mobile devices cannot be identified by their public IPv4
address alone.
The device should be identified by either the public (observed) IP address and port as seen by the application server, or the private (local) and any public (observed) IP addresses in use by the device (this information can be obtained by various means, for example from some DNS servers).
If the allocated and observed IP addresses are the same (i.e. NAT is not in use) then the same address should be specified for both publicAddress and privateAddress.
If NAT64 is in use, the device should be identified by its publicAddress and publicPort, or separately by its allocated IPv6 address (field ipv6Address of the Device object)
In all cases, publicAddress must be specified, along with at least one of either privateAddress or publicPort, dependent upon which is known. In general, mobile devices cannot be identified by their public IPv4 address alone.
The device should be identified by the observed IPv6 address, or by any single IPv6 address from within the subnet allocated to the device (e.g. adding ::0 to the /64 prefix).
The session shall apply to all IP flows between the device subnet and the specified application server, unless further restricted by the optional parameters devicePorts or applicationServerPorts.
A public identifier addressing a subscription in a mobile network. In 3GPP terminology, it corresponds to the GPSI formatted with the External Identifier ({Local Identifier}@{Domain Identifier}). Unlike the telephone number, the network access identifier is not subjected to portability ruling in force, and is individually managed by each operator.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with ’+’.
applicationServer: optional object { ipv4Address, ipv6Address } A server hosting backend applications to deliver some business logic to
clients.
The developer can choose to provide the below specified device
identifiers:
ipv4Addressipv6Address
The Operator will use this information to calculate the end to end
network performance in scenarios where its feasible.
A server hosting backend applications to deliver some business logic to clients.
The developer can choose to provide the below specified device identifiers:
ipv4Addressipv6Address
The Operator will use this information to calculate the end to end network performance in scenarios where its feasible.
IPv4 address may be specified in form <address/mask> as:
- address - an IPv4 number in dotted-quad form 1.2.3.4. Only this exact IP number will match the flow control rule.
- address/mask - an IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version.
IPv6 address may be specified in form <address/mask> as:
- address - The /128 subnet is optional for single addresses:
- 2001:db8:85a3:8d3:1319:8a2e:370:7344
- 2001:db8:85a3:8d3:1319:8a2e:370:7344/128
- address/mask - an IP v6 number with a mask:
- 2001:db8:85a3:8d3::0/64
- 2001:db8:85a3:8d3::/64
Set to true by API consumer if consumer wants to get an event as
soon as the subscription is created and current situation reflects
event request.
The subscription expiration time (in date-time format) requested by the API consumer. Up to API project decision to keep it. It must follow RFC 3339 and must have time zone.
Identifies the maximum number of event reports to be generated
(>=1) requested by the API consumer - Once this number is reached,
the subscription ends.
Note on combined usage of initialEvent and
subscriptionMaxEvents: If an event is triggered following
initialEvent set to true, this event will be counted towards
subscriptionMaxEvents.
Subscription object { config, protocol, sink, 5 more } Represents a event-type subscription.
Represents a event-type subscription.
Implementation-specific configuration parameters needed by the
subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime,
subscriptionMaxEvents, initialEvent
Specific event type attributes must be defined in subscriptionDetail
Note: if a request is performed for several event type, all subscribed
event will use same config parameters.
Implementation-specific configuration parameters needed by the
subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime,
subscriptionMaxEvents, initialEvent
Specific event type attributes must be defined in subscriptionDetail
Note: if a request is performed for several event type, all subscribed
event will use same config parameters.
subscriptionDetail: object { applicationProfileId, device, applicationServer, applicationServerPorts } The detail of the requested event subscription
The detail of the requested event subscription
device: object { ipv4Address, ipv6Address, networkAccessIdentifier, phoneNumber } End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators.
The developer can choose to provide the below specified device identifiers:
* ipv4Address
* ipv6Address
* phoneNumber
* networkAccessIdentifier
NOTE1: the network operator might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different network operators. In this case the identifiers MUST belong to the same device.
NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators.
The developer can choose to provide the below specified device identifiers:
* ipv4Address
* ipv6Address
* phoneNumber
* networkAccessIdentifier
NOTE1: the network operator might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different network operators. In this case the identifiers MUST belong to the same device.
NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
ipv4Address: optional object { privateAddress, publicAddress, publicPort } The device should be identified by either the public (observed) IP
address and port as seen by the application server, or the private
(local) and any public (observed) IP addresses in use by the device
(this information can be obtained by various means, for example from
some DNS servers).
If the allocated and observed IP addresses are the same (i.e. NAT is
not in use) then the same address should be specified for both
publicAddress and privateAddress.
If NAT64 is in use, the device should be identified by its
publicAddress and publicPort, or separately by its allocated IPv6
address (field ipv6Address of the Device object)
In all cases, publicAddress must be specified, along with at least one
of either privateAddress or publicPort, dependent upon which is known.
In general, mobile devices cannot be identified by their public IPv4
address alone.
The device should be identified by either the public (observed) IP address and port as seen by the application server, or the private (local) and any public (observed) IP addresses in use by the device (this information can be obtained by various means, for example from some DNS servers).
If the allocated and observed IP addresses are the same (i.e. NAT is not in use) then the same address should be specified for both publicAddress and privateAddress.
If NAT64 is in use, the device should be identified by its publicAddress and publicPort, or separately by its allocated IPv6 address (field ipv6Address of the Device object)
In all cases, publicAddress must be specified, along with at least one of either privateAddress or publicPort, dependent upon which is known. In general, mobile devices cannot be identified by their public IPv4 address alone.
The device should be identified by the observed IPv6 address, or by any single IPv6 address from within the subnet allocated to the device (e.g. adding ::0 to the /64 prefix).
The session shall apply to all IP flows between the device subnet and the specified application server, unless further restricted by the optional parameters devicePorts or applicationServerPorts.
A public identifier addressing a subscription in a mobile network. In 3GPP terminology, it corresponds to the GPSI formatted with the External Identifier ({Local Identifier}@{Domain Identifier}). Unlike the telephone number, the network access identifier is not subjected to portability ruling in force, and is individually managed by each operator.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with ’+’.
applicationServer: optional object { ipv4Address, ipv6Address } A server hosting backend applications to deliver some business logic to
clients.
The developer can choose to provide the below specified device
identifiers:
ipv4Addressipv6Address
The Operator will use this information to calculate the end to end
network performance in scenarios where its feasible.
A server hosting backend applications to deliver some business logic to clients.
The developer can choose to provide the below specified device identifiers:
ipv4Addressipv6Address
The Operator will use this information to calculate the end to end network performance in scenarios where its feasible.
IPv4 address may be specified in form <address/mask> as:
- address - an IPv4 number in dotted-quad form 1.2.3.4. Only this exact IP number will match the flow control rule.
- address/mask - an IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version.
IPv6 address may be specified in form <address/mask> as:
- address - The /128 subnet is optional for single addresses:
- 2001:db8:85a3:8d3:1319:8a2e:370:7344
- 2001:db8:85a3:8d3:1319:8a2e:370:7344/128
- address/mask - an IP v6 number with a mask:
- 2001:db8:85a3:8d3::0/64
- 2001:db8:85a3:8d3::/64
Set to true by API consumer if consumer wants to get an event as
soon as the subscription is created and current situation reflects
event request.
The subscription expiration time (in date-time format) requested by the API consumer. Up to API project decision to keep it. It must follow RFC 3339 and must have time zone.
Identifies the maximum number of event reports to be generated
(>=1) requested by the API consumer - Once this number is reached,
the subscription ends.
Note on combined usage of initialEvent and
subscriptionMaxEvents: If an event is triggered following
initialEvent set to true, this event will be counted towards
subscriptionMaxEvents.
Date when the event subscription will begin/began It must follow RFC 3339 and must have time zone.
Date when the event subscription will expire. Only provided when
subscriptionExpireTime is indicated by API client or Telco
Operator has specific policy about that.
It must follow RFC 3339 and must have time zone.
status: optional "ACTIVATION_REQUESTED" or "ACTIVE" or "EXPIRED" or 2 moreCurrent status of the subscription - Management of Subscription
State engine is not mandatory for now. Note not all statuses may
be considered to be implemented. Details:
ACTIVATION_REQUESTED: Subscription creation (POST) is
triggered but subscription creation process is not finished
yet.ACTIVE: Subscription creation process is completed.
Subscription is fully operative.DEACTIVE: Subscription is temporarily inactive, but its
workflow logic is not deleted.EXPIRED: Subscription is ended (no longer active).
This status applies when subscription is ended due to
SUBSCRIPTION_EXPIRED or ACCESS_TOKEN_EXPIRED event.DELETED: Subscription is ended as deleted (no longer
active). This status applies when subscription information is
kept (i.e. subscription workflow is no longer active but its
metainformation is kept).
Current status of the subscription - Management of Subscription State engine is not mandatory for now. Note not all statuses may be considered to be implemented. Details:
ACTIVATION_REQUESTED: Subscription creation (POST) is triggered but subscription creation process is not finished yet.ACTIVE: Subscription creation process is completed. Subscription is fully operative.DEACTIVE: Subscription is temporarily inactive, but its workflow logic is not deleted.EXPIRED: Subscription is ended (no longer active). This status applies when subscription is ended due toSUBSCRIPTION_EXPIREDorACCESS_TOKEN_EXPIREDevent.DELETED: Subscription is ended as deleted (no longer active). This status applies when subscription information is kept (i.e. subscription workflow is no longer active but its metainformation is kept).
Implementation-specific configuration parameters needed by the
subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime,
subscriptionMaxEvents, initialEvent
Specific event type attributes must be defined in subscriptionDetail
Note: if a request is performed for several event type, all subscribed
event will use same config parameters.
Implementation-specific configuration parameters needed by the
subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime,
subscriptionMaxEvents, initialEvent
Specific event type attributes must be defined in subscriptionDetail
Note: if a request is performed for several event type, all subscribed
event will use same config parameters.
subscriptionDetail: object { applicationProfileId, device, applicationServer, applicationServerPorts } The detail of the requested event subscription
The detail of the requested event subscription
device: object { ipv4Address, ipv6Address, networkAccessIdentifier, phoneNumber } End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators.
The developer can choose to provide the below specified device identifiers:
* ipv4Address
* ipv6Address
* phoneNumber
* networkAccessIdentifier
NOTE1: the network operator might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different network operators. In this case the identifiers MUST belong to the same device.
NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
End-user equipment able to connect to a mobile network. Examples of devices include smartphones or IoT sensors/actuators.
The developer can choose to provide the below specified device identifiers:
* ipv4Address
* ipv6Address
* phoneNumber
* networkAccessIdentifier
NOTE1: the network operator might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different network operators. In this case the identifiers MUST belong to the same device.
NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.
ipv4Address: optional object { privateAddress, publicAddress, publicPort } The device should be identified by either the public (observed) IP
address and port as seen by the application server, or the private
(local) and any public (observed) IP addresses in use by the device
(this information can be obtained by various means, for example from
some DNS servers).
If the allocated and observed IP addresses are the same (i.e. NAT is
not in use) then the same address should be specified for both
publicAddress and privateAddress.
If NAT64 is in use, the device should be identified by its
publicAddress and publicPort, or separately by its allocated IPv6
address (field ipv6Address of the Device object)
In all cases, publicAddress must be specified, along with at least one
of either privateAddress or publicPort, dependent upon which is known.
In general, mobile devices cannot be identified by their public IPv4
address alone.
The device should be identified by either the public (observed) IP address and port as seen by the application server, or the private (local) and any public (observed) IP addresses in use by the device (this information can be obtained by various means, for example from some DNS servers).
If the allocated and observed IP addresses are the same (i.e. NAT is not in use) then the same address should be specified for both publicAddress and privateAddress.
If NAT64 is in use, the device should be identified by its publicAddress and publicPort, or separately by its allocated IPv6 address (field ipv6Address of the Device object)
In all cases, publicAddress must be specified, along with at least one of either privateAddress or publicPort, dependent upon which is known. In general, mobile devices cannot be identified by their public IPv4 address alone.
The device should be identified by the observed IPv6 address, or by any single IPv6 address from within the subnet allocated to the device (e.g. adding ::0 to the /64 prefix).
The session shall apply to all IP flows between the device subnet and the specified application server, unless further restricted by the optional parameters devicePorts or applicationServerPorts.
A public identifier addressing a subscription in a mobile network. In 3GPP terminology, it corresponds to the GPSI formatted with the External Identifier ({Local Identifier}@{Domain Identifier}). Unlike the telephone number, the network access identifier is not subjected to portability ruling in force, and is individually managed by each operator.
A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with ’+’.
applicationServer: optional object { ipv4Address, ipv6Address } A server hosting backend applications to deliver some business logic to
clients.
The developer can choose to provide the below specified device
identifiers:
ipv4Addressipv6Address
The Operator will use this information to calculate the end to end
network performance in scenarios where its feasible.
A server hosting backend applications to deliver some business logic to clients.
The developer can choose to provide the below specified device identifiers:
ipv4Addressipv6Address
The Operator will use this information to calculate the end to end network performance in scenarios where its feasible.
IPv4 address may be specified in form <address/mask> as:
- address - an IPv4 number in dotted-quad form 1.2.3.4. Only this exact IP number will match the flow control rule.
- address/mask - an IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version.
IPv6 address may be specified in form <address/mask> as:
- address - The /128 subnet is optional for single addresses:
- 2001:db8:85a3:8d3:1319:8a2e:370:7344
- 2001:db8:85a3:8d3:1319:8a2e:370:7344/128
- address/mask - an IP v6 number with a mask:
- 2001:db8:85a3:8d3::0/64
- 2001:db8:85a3:8d3::/64
Set to true by API consumer if consumer wants to get an event as
soon as the subscription is created and current situation reflects
event request.
The subscription expiration time (in date-time format) requested by the API consumer. Up to API project decision to keep it. It must follow RFC 3339 and must have time zone.
Identifies the maximum number of event reports to be generated
(>=1) requested by the API consumer - Once this number is reached,
the subscription ends.
Note on combined usage of initialEvent and
subscriptionMaxEvents: If an event is triggered following
initialEvent set to true, this event will be counted towards
subscriptionMaxEvents.
Date when the event subscription will begin/began It must follow RFC 3339 and must have time zone.
Date when the event subscription will expire. Only provided when
subscriptionExpireTime is indicated by API client or Telco
Operator has specific policy about that.
It must follow RFC 3339 and must have time zone.
status: optional "ACTIVATION_REQUESTED" or "ACTIVE" or "EXPIRED" or 2 moreCurrent status of the subscription - Management of Subscription
State engine is not mandatory for now. Note not all statuses may
be considered to be implemented. Details:
ACTIVATION_REQUESTED: Subscription creation (POST) is
triggered but subscription creation process is not finished
yet.ACTIVE: Subscription creation process is completed.
Subscription is fully operative.DEACTIVE: Subscription is temporarily inactive, but its
workflow logic is not deleted.EXPIRED: Subscription is ended (no longer active).
This status applies when subscription is ended due to
SUBSCRIPTION_EXPIRED or ACCESS_TOKEN_EXPIRED event.DELETED: Subscription is ended as deleted (no longer
active). This status applies when subscription information is
kept (i.e. subscription workflow is no longer active but its
metainformation is kept).
Current status of the subscription - Management of Subscription State engine is not mandatory for now. Note not all statuses may be considered to be implemented. Details:
ACTIVATION_REQUESTED: Subscription creation (POST) is triggered but subscription creation process is not finished yet.ACTIVE: Subscription creation process is completed. Subscription is fully operative.DEACTIVE: Subscription is temporarily inactive, but its workflow logic is not deleted.EXPIRED: Subscription is ended (no longer active). This status applies when subscription is ended due toSUBSCRIPTION_EXPIREDorACCESS_TOKEN_EXPIREDevent.DELETED: Subscription is ended as deleted (no longer active). This status applies when subscription information is kept (i.e. subscription workflow is no longer active but its metainformation is kept).