Shrink datatypes where practical -- an "hour" or "quarter" does not need a 4-byte INT does it? How about TINYINT UNSIGNED (range of 0..255), which takes only 1 byte.
BIGINT? That's 8 bytes; do you really need more than 4 billion values? INT UNSIGNED is 4 bytes.
TIMESTAMP is 4 bytes; DATETIME is 8.
> schema is normalized
You have 3 VARCHARs. What are the values like? Are they mostly repeated? If so, normalize them, too.
key_buffer_size is set in my.ini (my.cnf). It controls how much index space to allocate in RAM. See
http://mysql.rjweb.org/doc.php/memory
With those changes, the disk footprint might be cut in half. (Smaller -> faster.)
select c.msisdn,sum(c.dataVolumeDownLink+c.dataVolumeUpLink) as datasum
from cdr c
where c.eventDate >= <date_var>
group by c.msisdn
order by datasum desc;
That smells like something that can (should!) be periodically (and incrementally) rolled into a summary table. (See my links.)
Open question: Will you be purging 'old' data? If so, PARTITION by eventDate. If not, then I don't yet seen any use for PARTITIONing.
With a summary table, you won't need the secondary keys; this will significantly speed up inserts. And the SELECT will probably run 10 times as fast against the summary table.
Back to your question:
> which is better indexing or partitioning
Tentatively, I say neither -- summary table is what you need.