Are there any many to one encryption frameworks available? I am reasonably new to the cryptography. For my use-case I need a method where in I would need a receiver to accept encrypted messages from a range of senders (each having their own, say, public key). My use-case also needs that some of these users only have temporary access which can be revoked externally i.e. without explicitly telling the receiver but ensuring that receiver can no longer honour the encrypted messages from those senders.

Its very similar to the way public wifi hotspots work. Assuming the receiver is the Wifi Router, and each sender has their own passphrase which is short lived for the duration of the subscription. 

However in this use-case there is no single receiver, but a network of receivers. All of them talk to each other using a common encryption key. What I am looking for is to have 


an encryption key to be a function of multiple sender's public keys. 
all of the receivers and the senders can decrypt the messages which were encrypted with that encryption key.
Adding a new sender should be fairly less complex (I guess we need the encryption key to be updated in this case, but if any of the receivers missed the update how can they get attached again?)
Removing a sender should be fairly less complex (Again I guess we need the encryption key to be updated which again comes with the case of how to deal with receivers missing such an update)


Could you please help point such an encryption technique already in place and possibly proven to be secure? Many thanks and please ask if you need further information to answer my query.
What you ask for is possible, but only (I'm pretty certain, although I don't have any sort of formal proof) if there is a central authority who has a separate, secured connection to each user. Also, the concept of public keys becomes unnecessary. If the encryption and decryption key is a function of "public keys", then any user who at any point was a member of the system will be able to encrypt or decrypt messages. To show what I'm talking about, let's build the following system.

We have users $u_1, \ldots u_n$. Let's say that $u_1$ is the authority, and can revoke any user's access to the system. We have a shared encryption key, $k_s$, which is known to all $u_i$ and $k_s$ is determined by some key derivation function $KDER(pub_{u_1}, \ldots pub_{u_n})$. 

If $KDER$ is public (i.e., the new key is derived by each user from the public keys), then we have the following problem. Let's say the user getting booted is $u_{n}$. If $KDER$ is public, it is trivial for $u_n$ to attack the system, as they know $KDER$ and know $pub_{u_1}, \ldots pub_{u_{n-1}}$, and can therefore derive the new key. 

So the concept of using public keys doesn't quite make sense. So instead of referring to them as $pub_{u_i}$, let's consider them as $tok_{u_i}$, which is private token randomly generated by the central authority. Now, $KDER$ is private, and $u_1$ must distribute the new encryption key using his secure channels. At this point, the users can all use the new key for sending messages, and the booted user won't be able to attack the system.

Having a central authority seems like it should work for you, because of the line:


  My use-case also needs that some of these users only have temporary access which can be revoked externally


Which seems to imply that there is some sort of authoritative actor within or without the system. But if this is not the case I don't believe what you're asking for is possible. For this to be decentralized, every user within the system, including the user who was just removed, must have the ability to create the new key. Crypto has some nice tools for granting access after an amount of time $t$ (proof-of-work systems and so on, see this question), however I do not believe there are any systems which grant access for some amount of time that do not require a central authority.

I really hope I'm mistaken, because such a system would have some very interesting use cases, but if you think about it it doesn't quite make sense. Someone needs to decide when a user's access is up.