Subscriptions
Device Reachability Status Subscriptions
Create a device reachability status event subscription for a device
Retrieve a list of device reachability status event subscription
Retrieve a device reachability status event subscription for a device
Delete a device reachability status event subscription for a device
ModelsExpand Collapse
DeviceReachabilityStatusConfig 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 { device } The detail of the requested event subscription.
The detail of the requested event subscription.
device: optional 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
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 ’+’.
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 subscribes to reachability SMS. If consumer sets initialEvent to true and device is already reachable by SMS, an event is triggered.
DeviceReachabilityStatusSubscription 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.
config: DeviceReachabilityStatusConfig { 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 { device } The detail of the requested event subscription.
The detail of the requested event subscription.
device: optional 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
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 ’+’.
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 subscribes to reachability SMS. If consumer sets initialEvent to true and device is already reachable by SMS, an event is triggered.
Camara Event types eligible to be delivered by this subscription.
Note: For the current Commonalities API design guidelines, only one event type per subscription is allowed
Camara Event types eligible to be delivered by this subscription. Note: For the current Commonalities API design guidelines, only one event type per subscription is allowed
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.
Recommended format is yyyy-MM-dd’T’HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
Date when the event subscription will begin/began It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd’T’HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
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).
DeviceReachabilityStatusSubscriptionEventType = "org.camaraproject.device-reachability-status-subscriptions.v0.reachability-data" or "org.camaraproject.device-reachability-status-subscriptions.v0.reachability-sms" or "org.camaraproject.device-reachability-status-subscriptions.v0.reachability-disconnected"reachability-data - Event triggered when the device is connected to the network for Data usage (regardless of the SMS reachability).
reachability-sms - Event triggered when the device is connected to the network only for SMS usage
reachability-disconnected - Event triggered when the device is not connected.
reachability-data - Event triggered when the device is connected to the network for Data usage (regardless of the SMS reachability).
reachability-sms - Event triggered when the device is connected to the network only for SMS usage
reachability-disconnected - Event triggered when the device is not connected.
SubscriptionListResponse = array of DeviceReachabilityStatusSubscription { id, config, protocol, 5 more }
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.
config: DeviceReachabilityStatusConfig { 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 { device } The detail of the requested event subscription.
The detail of the requested event subscription.
device: optional 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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
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:
ipv4Addressipv6AddressphoneNumbernetworkAccessIdentifier
NOTE: the MNO might support only a subset of these options. The API invoker can provide multiple identifiers to be compatible across different MNOs. In this case the identifiers MUST belong to the same device.
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 ’+’.
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 subscribes to reachability SMS. If consumer sets initialEvent to true and device is already reachable by SMS, an event is triggered.
Camara Event types eligible to be delivered by this subscription.
Note: For the current Commonalities API design guidelines, only one event type per subscription is allowed
Camara Event types eligible to be delivered by this subscription. Note: For the current Commonalities API design guidelines, only one event type per subscription is allowed
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.
Recommended format is yyyy-MM-dd’T’HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
Date when the event subscription will begin/began It must follow RFC 3339 and must have time zone. Recommended format is yyyy-MM-dd’T’HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
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).