Data Push Signal Notification Orchestrator Network Service to replace push notification supporting radio over the air communication improvements

Wesley Oliver <wesley.olis@gmail.com> Thu, 19 September 2019 07:20 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1781012013D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Sep 2019 00:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.988
X-Spam-Level:
X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV9eQK_CXS6k for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Sep 2019 00:20:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A914F12012D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 19 Sep 2019 00:20:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iAqhS-0004R9-TP for ietf-http-wg-dist@listhub.w3.org; Thu, 19 Sep 2019 07:17:58 +0000
Resent-Date: Thu, 19 Sep 2019 07:17:58 +0000
Resent-Message-Id: <E1iAqhS-0004R9-TP@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <wesley.olis@gmail.com>) id 1iAqhP-0004QO-Er for ietf-http-wg@listhub.w3.org; Thu, 19 Sep 2019 07:17:55 +0000
Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <wesley.olis@gmail.com>) id 1iAqhN-0006FX-6T for ietf-http-wg@w3.org; Thu, 19 Sep 2019 07:17:55 +0000
Received: by mail-pg1-x533.google.com with SMTP id m29so1355942pgc.3 for <ietf-http-wg@w3.org>; Thu, 19 Sep 2019 00:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=15L00/hmhe9QMNXbVU5klpIhfVUqdea8YI2/j3LtO5Y=; b=bRzh5QUHK59fUcS9fuNP/U2oh6+xOGGEE8VFx1yq/rEq54aoN0rT+8qLEgyDMjH+KI bNXIAS4MqcVvPscYqa3QagXvKUuVAO93WCssfCrgEoagnE0upaiJoLvQ9viis7lj2LIz vs8ptxFE1OLwtoZPHYBkraYqMhV1amy2tOW+nEJXfyRVVzieLY5jyDOVFnCerwaJaVNl ftf6AINWA6RWKVasKtvpFV/03aesIsDgtFsK5byH3FUMYYqSyf2XOOKiod2dj8Iwoxfx 1Z1326nkPP2aYZbjk/BvY8MMeH5HBcrtHGzbHnsMj1SikeZQwUhfF0eqWl+QQgZ3bL42 BnIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=15L00/hmhe9QMNXbVU5klpIhfVUqdea8YI2/j3LtO5Y=; b=bn8khv6VtlJwtdzK3N0y+wq4ymViFM+uvns3N0L+8ohBuX/SFbeMG1KckoR3b2IAps teV7iXj5yRObTH4CA+ExmphH2RBXQOw3TS3wPIfe4p7No20bSj/pWSH3odcYO9K7xe3p q23c51pBgFCY8AIKNj+QuawQBNrgQntEsBC9OB/TAufanU2cQhSseDSjur1TEcWV/o+m rfZfM7tsiJMZh6db2qXoLJXBtX1H5BuH7Ph6/VN1O/UAb0PGBxYP9mCVUYK/Lqeowdy+ 7NzB5/Rj7lzf360m+9/FRrIuibhHfiUWQO0/3PHuOEvx4nmawDdsDPvmidm7JbcVnN7O r94w==
X-Gm-Message-State: APjAAAXHiEZdLdIZ3kPVYPjswYH4WYdaatuxtjfrSksLWFJXCmbF6I11 XaTRvBIdIQmeQgHZCFuhfaywvLfEo2XMM2rWCYdfqYeaWOk=
X-Google-Smtp-Source: APXvYqzFirSiDyehMT7ioUeD/OfUJTuHARMxZrSsv5NfE4CBxe8pyaFue6ZrpMky4+Fw0bOL8zylaKzTT8HvRj7Pf0s=
X-Received: by 2002:a63:be48:: with SMTP id g8mr7596471pgo.193.1568877450787; Thu, 19 Sep 2019 00:17:30 -0700 (PDT)
MIME-Version: 1.0
From: Wesley Oliver <wesley.olis@gmail.com>
Date: Thu, 19 Sep 2019 09:17:19 +0200
Message-ID: <CACvHZ2Z48GQTBarhE8to4p5O9hhw4vUttOYAHLigdnpwWNLERA@mail.gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000002682360592e2bfa5"
Received-SPF: pass client-ip=2607:f8b0:4864:20::533; envelope-from=wesley.olis@gmail.com; helo=mail-pg1-x533.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iAqhN-0006FX-6T 10f4d5a3a4e2ec9c7cf2c107c9bc447d
X-Original-To: ietf-http-wg@w3.org
Subject: Data Push Signal Notification Orchestrator Network Service to replace push notification supporting radio over the air communication improvements
Archived-At: <https://www.w3.org/mid/CACvHZ2Z48GQTBarhE8to4p5O9hhw4vUttOYAHLigdnpwWNLERA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37023
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi,

Guys just a general idea, let me know what you think.

https://docs.google.com/document/d/17r9BZAfjrimEo2DEMHRNZ930c5vBwrF8VH9VirrWWj4/edit?usp=sharing

https://datatracker.ietf.org/doc/rfc7540/?include_text=1

Rough Draft - 19 September 2019

Data Push Signal Notification Orchestrator Network Service - 19 September
2019

One has become so used to push notification one forgets that they rely on
centralized infrastructure which is provided by a monopoly provider. The
problem with this is every country is reliant on well Google and the OS to
provide good scheduling and reduce the network overheads and save battery
life by efficiently coordinate data exchange over the air.

It has come to a time, where I feel, with all the trade wars, that only
have a single entity that can be cut off and cause many mechanisms that we
use to stop and not be available to all, that we implement a better
solution to push notifications that can be integrated and optimized down to
hardware level.


Proposal

Implement a new network service called, Data Push Signal Notification
Orchestrator (DPSNO), which would be something similar to a DNS service.

How to identify the service on the network would be in one of the following
two ways.

1. DHCP server typically would provide gateway and DNS service and few
other settings,

a DHCP server will now also provide primary and secondary DPSNO service to
over the air devices and LAN devices.

2. DNS conventional entry like good old proxy.dat file entry that
webbrowser/os would look for dynamic configuration of proxies. In the same
way, a device will query there primary and secondary DNS for the IP of the
DPSNO service is running on.


What does the DPSNO service functionality provide


   1.

   The client device will send it a list of service that would like to
   interact with it via a push notification type mechanism, this service will
   the inform each service that they are the push notification service to
   communicate with for this device. This would allow any service that wants
   to push notification, to connect to this DPSNO service and query a message
   for delivery to a client.


One problem to still deal with is if there is a change over of DPSNO
service, new configuration is handed out, won’t be able to contract the old
service again, because
network traffic will have limited flow and only be in a single direction.
Require a mechanism for this, that the originating service, that queues
messages via DPSNO, will be notified of a new registration when notified of
the new registration, the device will send the last GUID message received
to the DPSNO, which will be forward to originating service to notify them
of the new DPSNO to use to communicate with there intended device.


   1.

   This service will queue all message until the device connects and allows
   for a data push, which actually just a data download if the connection was
   no longer open.



   1.

   If there is no current open connection channel to the device then this
   service will notify the registered over the air radio device, to signal
   that device that there is a push-type notification available for it to
   download. There are a few different types of push notifications, which will
   allow for more efficient optimization of battery life.
   Each radio over the air device, will for 4G, 5G, Wifi, Wired(wake
   notification) implement a hardware-specific tweak to there signal
   protocols, to signal a device, to checking to retrieved push notifications.

   2.

   Provide connection mechanism for UDP, TCP to maintenance a longer-term
   connection.




Types of push notifications

We can potentially allow 16 values or 4 bytes of information with the
signal trigger to be communicated to the device at the same time. These
values would be a voice call, video call, realTime Interaction (tsunami
warning), Message Interactive Chat, Information.


Basically, every single application can be classified and group, there are
only 16 values, so the local device when they register with the DPSNO for
each service that wants get push notifications forwarded to them, will
communicate which application identifiers are group under which 16 values.

A non real-time event, will allow the os to communicate that there is a
message, like with flashing light or vibration, however, will only
communicate with the DPSNO server when

The device is powered on and wakes out of deep sleep, for the operator/user
to view the message. This ensures that the least amount of wakes and sleeps
are necessary.

The signal and 4 bytes of information can in future have a radio
manufacture, were by when the signal is sent, that it energies a bandgap,
which triggers the phone into operation, there allowing the electronics of
the radio to be totally turned off, until the bandgap of the signal causes
it to turn on.

Could look at communicating the typical payload size of the message, so
that the client DPSNO

Can better ascertain when to wake and connect, as there is sufficient
network quality. One can never predict if there is going to be better
network connectivity.

Operating Systems DPSNO

This client implementation of DPSNO, will manage and acts as an
intermediary between the device services trying to receive push
notifications so that it to gather with the os and network radio and
optimize and reduce battery usage. Can design the client in such a way,
that if there is no DPSNo server available, that it will manage and then
perform long polling those services efficiently or contact another DPSNO
server to perform all the long polling for all the registered services and
return the aggregated results. Typically these would be DPSNO server, that
don’t have the over the air radio communication device that is connected to
it, so it would rather employer long polling aggregation technic.

LTE Integration

At a high level, the radio link can be in idle stat or connected state, So
what we could look into doing is implement another transition state from
idle to connected state, which is signal transition to the connected state,
which the device, will then know it needs to check in with the DPSNO server.

Kind Regards,

Wesley Oliver

-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis@gmail.com