Query Tuning and Index Tuning - SQL Server
I am an Oracle Developer. Based on my understanding of Oracle performance tuning, this is how I would approach your situation.

I am seeing three entry points to your SQL.

a. xMobiles
b. xDrivers
c. GPSTime endpoints.


Each entry point will produce a different execution plan. Based on the selectivity of rows upfront in the execution plan tree, the best plan needs to be selected dynamically. Go through the data volume that gets generated at each step for the three possible execution plans. That will give you a good insight into the fact that "which plan suits your particular scenario".

Regarding your first execution plan, you have stated that the number of Actual Rows from dbo.Logs is 230768 and the Clustered Index(CI) Scan is showing 5676246 (24x greater). 

Please note the difference between "SEEKs" and "SCANs". IX_Log_NodeID1 was accessed via an Index Seek. This uses the predicate values passed for that index and seeks only those rowids matching the predicate values. It does not scan the entire index. Whereas, in step two of the execution plan, the entire CI PK_LogMobiles is scanned into memory and only then a nested loop is performed. This is not optimal.

That is our issue. In step two PK_LogMobiles must be accessed via CI Seek, seeking only the 230768 logIDs out of the entire 5676246 logIDs. Instead the entire CI is scanned.

In Oracle such scenarios arise when the 230768 rows are scattered across too many pages (SQLServer) or blocks (Oracle) causing a major part / the entire CI to be scanned. This means that the records are not clustered enough for seeks. Improve the ClusteringFactor (Oracle Terminology) of your so called CI to resolve your performance issue.