Subscriptions
Device Geofencing Subscriptions
Create a geofencing subscription for a device
Retrieve a list of geofencing event subscription
Operation to retrieve a subscription based on the provided ID
Delete a Geofencing event subscription
ModelsExpand Collapse
DeviceLocationConfig object { initialEvent, subscriptionExpireTime, subscriptionMaxEvents } Implementation-specific configuration parameters are needed by the subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime, subscriptionMaxEvents, initialEvent.
Implementation-specific configuration parameters are needed by the subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime, subscriptionMaxEvents, initialEvent.
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.
Example: Consumer request area entered event. If consumer sets initialEvent to true and device is already in the geofence, an event is triggered.
The subscription expiration time (in date-time format) requested by the API consumer. 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.
DeviceLocationDevice object { ipv4Address, ipv6Address, networkAccessIdentifier, phoneNumber } End-user device 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE1: the API provider might support only a subset of these options. The API consumer can provide multiple identifiers to be compatible across different API providers. In this case the identifiers MUST belong to the same device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the response or event.
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 device 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE1: the API provider might support only a subset of these options. The API consumer can provide multiple identifiers to be compatible across different API providers. In this case the identifiers MUST belong to the same device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the response or event. 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).
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 ’+’.
DeviceLocationSubscription object { id, config, protocol, 5 more } Represents a event-type subscription.
Represents a event-type subscription.
The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as subscriptionId as per Commonalities Event Notification Model.
Implementation-specific configuration parameters are needed by the subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime, subscriptionMaxEvents, initialEvent.
Implementation-specific configuration parameters are needed by the subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime, subscriptionMaxEvents, initialEvent.
subscriptionDetail: object { area, device } The detail of the event subscription granted by the implementation.
The detail of the event subscription granted by the implementation.
The geofencing area where the monitor is active. This area is specified by API consumers in the subscription request. The same area definition is included in event notifications without any modifications.
The geofencing area where the monitor is active. This area is specified by API consumers in the subscription request. The same area definition is included in event notifications without any modifications.
device: optional DeviceLocationDevice { ipv4Address, ipv6Address, networkAccessIdentifier, phoneNumber } End-user device 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE1: the API provider might support only a subset of these options. The API consumer can provide multiple identifiers to be compatible across different API providers. In this case the identifiers MUST belong to the same device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the response or event.
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 device 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE1: the API provider might support only a subset of these options. The API consumer can provide multiple identifiers to be compatible across different API providers. In this case the identifiers MUST belong to the same device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the response or event. 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).
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 ’+’.
Date when the event subscription will begin/began It must follow RFC 3339 and must have time zone.
Camara Event types eligible to be delivered by this subscription.
Note: As of now we enforce to have only event type per subscription.
Camara Event types eligible to be delivered by this subscription. Note: As of now we enforce to have only event type per subscription.
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.INACTIVE: 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 meta-information 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.INACTIVE: 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 meta-information is kept).
The unique identifier of the subscription in the scope of the subscription manager. When this information is contained within an event notification, this concept SHALL be referred as subscriptionId as per Commonalities Event Notification Model.
Implementation-specific configuration parameters are needed by the subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime, subscriptionMaxEvents, initialEvent.
Implementation-specific configuration parameters are needed by the subscription manager for acquiring events.
In CAMARA we have predefined attributes like subscriptionExpireTime, subscriptionMaxEvents, initialEvent.
subscriptionDetail: object { area, device } The detail of the event subscription granted by the implementation.
The detail of the event subscription granted by the implementation.
The geofencing area where the monitor is active. This area is specified by API consumers in the subscription request. The same area definition is included in event notifications without any modifications.
The geofencing area where the monitor is active. This area is specified by API consumers in the subscription request. The same area definition is included in event notifications without any modifications.
device: optional DeviceLocationDevice { ipv4Address, ipv6Address, networkAccessIdentifier, phoneNumber } End-user device 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE1: the API provider might support only a subset of these options. The API consumer can provide multiple identifiers to be compatible across different API providers. In this case the identifiers MUST belong to the same device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the response or event.
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 device 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE1: the API provider might support only a subset of these options. The API consumer can provide multiple identifiers to be compatible across different API providers. In this case the identifiers MUST belong to the same device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the response or event. 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).
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 ’+’.
Date when the event subscription will begin/began It must follow RFC 3339 and must have time zone.
Camara Event types eligible to be delivered by this subscription.
Note: As of now we enforce to have only event type per subscription.
Camara Event types eligible to be delivered by this subscription. Note: As of now we enforce to have only event type per subscription.
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.INACTIVE: 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 meta-information 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.INACTIVE: 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 meta-information is kept).