In addition to class C not really being supported at present, even if it were supported it would not really leverage the unique capability of a LoRaWAN gateway, since the “unexpected” transmissions have to be on the single spreading factor and frequency monitored by the node.
Given all this, if the network is downlink “only” or “mostly” the asker may want to consider just building a lightweight point-to-point (or point to multi-point) scheme on top of plain LoRa, rather than LoRaWAN or TTN. Or for more mixed usage using a private instance of a network server which does support this.
While being a part of TTN is in general a good thing, because a gateway stops being able to receive from any node while transmitting, usage with a high ratio of downlinks doesn’t work well in LoRaWAN, and especially not in a shared settings such as TTN.
If someone wanted to be really clever they could probably even run the uplink path of their node through TTN but route an off-the-clock downlink outside of TTN and instead through a node class radio sitting on a little Internet connected Linux box somewhere in range. Granted, due to fcnt tracking this would require the node to either track a second keys / fcnt combination for off-the-books downlinks, or not accept any downlinks from TTN at all ever.